Skip to content

WebRTC

WebRTC Digest – Week of 6/3 – IE, Hype, and Security

WebRTC in IE?

A blog post and some tweets from a Microsoft developer conference seemed to suggest that Microsoft is making progress on WebRTC in IE (at least in the context of running Lync without a plugin). There appear to be no details on whether it is CU-WebRTC, vanilla WebRTC, or something else entirely.

Hype Recheck

While Cisco continued to re-blog last week’s “The Reality of WebRTC
 All Hype?” article several times, Tsahi Levent-Levi posted a rebuttal stating:

WebRTC is the most disruptive technology in VoIP to date. Not because there’s new technology in it, but because it enables new use cases to be implemented.

Security and WebRTC

Recent news spawned a discussion about WebRTC security and privacy. Chrome WebRTC Team Lead Justin Uberti shared a post, written by Mozilla employee Adam Roach, that provides a nice overview of the issues: “WebRTC: Security and Confidentiality”. Cullen Jennings, Cisco employee and RTCWeb co-chair, was one of many contributors to a recently written report outlining the dangers of adding wiretap endpoints to Internet services.

Tunneling WebRTC over TCP (and why it matters)

A couple of weeks ago, we quietly turned on support for dual-sided TCP tunneling in the vLine Cloud, becoming the first WebRTC infrastructure provider to support connecting through firewalls that block UDP. This may not sound interesting or important, but it actually makes the difference between having a service that “usually connects” and one that “just works”. Let us explain:

One of the many great things about WebRTC is that it’s relatively easy to get started. Bring up an instance of the apprtc backend for signaling, copy and paste some JavaScript, and, voila, you’re making video calls in your app (actually, it’s a little harder than that, but a good web developer can easily have demoable video chat up and running in a day or two).

Unfortunately, the road from demo to production-grade service can be more challenging than you might expect (and more expensive!). Here’s how it usually goes: 

Level 1: STUN

You start by making your first few calls over a local area network, and everything works great. Hooray! Then you try to make a call to someone outside your firewall, and one of two things will happen.

1) If you happened to copy and paste the address of Google’s STUN server from the apprtc source code, your call will go through, and you’ll be a happy camper (though you may have some lingering doubts about whether it’s ok to use an undocumented service that Google has not given third party developers explicit permission to use. Note the silence from Google on this thread).

2) If you don’t have a STUN server configured, your call will fail. A little research will reveal that STUN is a protocol that the browser uses to determine its public IP address and poke a hole in the firewall. So, if you want to connect through a firewall, you’ll need a STUN server.  A few hours later you have an open source server up and running on EC2. A small instance should do just fine ($43.92 per month), but you’ll probably want to run at least two of them for availability, preferably in different regions (make that $87.84 per month).

Level 2: TURN

You do a few more test calls, and they all work. Things are looking good. Then you try to make a call between two corporate networks, and it fails. Grrr. While you were researching STUN, you read about another protocol called TURN that’s used to relay data in cases when the browser can’t establish a peer-to-peer connection. You weren’t sure if it was strictly necessary, but some more research reveals that STUN is only sufficient for connecting about 80% of calls. If that’s not enough for you (and it probably isn’t), you’ll need a TURN server.

A few mailing list threads later, and you’ve got a TURN server up and running on your EC2 instance. Actually, the network throughput on a small instance can be pretty unpredictable, if anyone else is using your shared network interface, so you should think about getting a bigger instance. A medium instance ($87.84 per month) works pretty well, but for the most predictability and lowest jitter, you’ll want an extra large ($351.36 per month), which will get you “high network performance”. Actually, make that two ($703.52 per month), for availability.

Of course, since you’re relaying video, you’ll need to factor in the bandwidth costs as well. Base pricing on EC2 is $0.12 per GB. As you’re running the numbers on this, you may start to wonder what prevents someone else from using that public server you just set up and running up your bandwidth bills. Here’s a good mailing list thread on the subject. Summary: there’s not a great way to prevent this given the way the TURN protocol works and that the TURN credentials have to be present in your JavaScript, where anyone can find them.

But let’s not get caught up in the dollars and cents. You can now make calls to your friends at other tech companies. Awesome! Then you try to make a call to someone at a big, corporate, non-tech company, and it fails. Dad-gum. You thought TURN had you covered.

20 minutes later, after a little more research, you discover that Chrome’s TURN allocation implementation only supports relaying UDP packets. Chrome 28 will add support for allocating a TURN server over TCP, but the packets will still be relayed through UDP. Whoops, that still doesn’t solve your problem when the firewall blocks UDP traffic. 

Level 3: vLine Cloud

This is when our new TCP-tunneling support comes into play. It doesn’t rely on Chrome’s TURN implementation, so it works in Chrome today. Furthermore, it works even if both parties are behind firewalls that block UDP. All that’s required is access to the internet over port 443 (the HTTPS port), which the vast majority of firewalls allow.

You don’t need to do anything special to enable TCP tunneling in your vLine service. Just use vline.js to build your app, and we’ll connect using the best available method for any given call. We run a highly-available global network of servers, so we’ll provide the best possible call quality to all of your users, anywhere in the world, even behind firewalls that block everything except TCP traffic over the HTTPS port. In case you’re wondering, we’re still doing end-to-end DTLS, so our servers never see your unencrypted media streams.

Our goal is a 100% connect rate. If you have a network where calls aren’t connecting, please let us know.

Note 1: If you want to test this yourself by blocking UDP on your firewall, remember to leave the DNS port (53) open.

Note 2: Some ultra-restrictive firewalls that do stateful packet inspection may still block connections since, even though the browser is using the HTTPS port, it isn’t actually doing SSL/TLS (we’ve never actually encountered a firewall like this in the wild, but they do exist). Chrome will soon support making WebRTC connections over TLS, at which point we will work through these firewalls, as well.

WebRTC + Chromebox = $400 HD Telepresence System

WebRTC Digest – Week of 5/27 – Flow Charts, FUD, and T-Shirts

Good in-depth explanations of WebRTC are still few and far between. Fortunately, Anant Narayanan of Firebase (and previously the WebRTC team at Mozilla) made a big contribution to the presentation-pool last week with his talk A Practical Introduction to WebRTC at Fluent Conference.

Be sure to check out the slides for the most complete set of WebRTC signaling flowcharts on the web (use the down arrow on slide 7). Seriously. if you want to understand what’s going on under the hood when you click “Start Call” in a WebRTC app, you need to read the flowcharts. We’ll wait.

FUDdy-duddy

WebRTC was top of mind over at No Jitter last week, with no fewer than three posts on the topic. Irwin Lazar of Nemertes Research led off with a positive piece titled WebRTC: Why Should Enterprises care?

Perhaps more exciting is the opportunity to give CRM or ERP applications their own voice/video applications directly embedded into their web interfaces [
] Think about a team of people who live in a business process application all day who can chat, talk, or video chat with each other [
] Again, here the opportunities are endless for application developers to extend rich communications and collaboration anywhere.

Then Laurent Philonenko, VP/GM of Cisco’s Clients and Mobility Business Unit rained on the WebRTC parade with The Reality of WebRTC
All Hype?

[
] WebRTC is not quite ready for prime time. Simply put, the standards are not done. Assume the WebRTC standards completion is still one year out, and that it takes six months for Chrome and Firefox to ship a browser with the final standards; plus add the time for people to upgrade their browsers. We’ll see early implementations before, but I’d say it’s two-plus years before this technology is widely deployed in the market.

Dave Michels closed out with WebRTC Hype Check, kindly explaining that there’s nothing to see here, and you folks should really just move along.

WebRTC is not disruptive. [
] WebRTC does not offer new capabilities, nor significant cost savings over other peer-to-peer technologies. WebRTC could be more accurately described as an evolutionary technology–effectively bringing real-time capabilities to the browser instead of reliance on ad-hoc plugins and downloads.

We’re biting our tongues for now, but you can expect to hear more on this subject here on the vLine Blog. In the meantime, we’ll be polishing up the design on our new line of “WebRTC Is Ready” T-Shirts.

Seriously. Drop us a line if you’d like one.

GitTogether: Video Chat for GitHub (powered by WebRTC)

tl;dr

  1. Go to gittogether and login with GitHub.
  2. See people you follow on GitHub plus members of your teams and organizations as contacts.
  3. If the people you want to talk to aren’t online or aren’t in your contact list, send them your GitTogether url (gittogether GitHub).
  4. Chat away!

Background

It’s hard to know if your platform is any good until you’ve used it to build a real app, preferably one that you use yourself on a daily basis. So, when we first started developing the vLine platform and API two years ago, we also started building an app on top of it.

Since our lives basically revolve around GitHub, we decided to build a communications tool that does, too. We named it GitTogether, gave it a GitHub login, and populated the contacts list from the people you follow or work with on GitHub.

Fast-forward to today, and we have a robust app that we’ve been using internally as our primary communications tool for over a year. Since our main goal was to learn from the experience of building and using it, we never shared it very widely, but enough people have discovered it and found it useful that we figured we should finally spend some more time talking about it.

Over the next few weeks, we’re going to do a series of blog posts on how it works under the hood, what we learned from the process of building it, and how you can build apps that share the same capabilities. But in the meantime, enjoy!

WebRTC Digest – Week of 5/20 – Chrome 27, Temporal Scalability & Hardware Acceleration

Chrome 27

Chrome 27 was officially released. A list of WebRTC-related changes is available on the discuss-webrtc mailing list. One of the most visible changes as an end-user is the ability to select the camera and microphone from the “Omnibox” rather than digging through the Chrome settings.

Temporal Scalability

There was an interesting discussion on the mailing list about temporal scalability and whether controls for it could be exposed in WebRTC through SDP, especially for use with conferencing/mixing. Temporal scalability is a method of encoding a video stream in a format that lets you decode it at multiple frame rates (e.g., 30 FPS or 15 FPS) at the cost of increased encoding overhead. The LifeSize blog provides a nice description in the context of the H264 codec, and the WebM mailing list has a more detailed technical description of how it works in VP8.

Hardware Acceleration

VP8 hardware acceleration continues to be supported by more platforms as nVidia shows with this Tegra 4 demo of 1080p videoconferencing at 30 FPS. The Tegra 4 will have built-in hardware support for both VP8 encoding and decoding, with a stated goal of

Delivering the best WebRTC experience on Android, Chrome OS, and Google TV.

WebRTC Digest – Week of 5/13 – BB10, Firefox 22 & Google IO

WebRTC on Blackberry 10

Our friends at Hookflash kicked off the week by announcing support for WebRTC on Blackberry 10. Erik Lagerway followed up on webrtc-discuss:

Just thought I would let everyone know that we have finished porting Google’s WebRTC media stack in entirety to QNX / Blackberry 10. Currently in our Open Peer github repo, we plan on getting this back upstream, if Google will have it.

WebRTC Tech Lead Justin Uberti, welcomed the news and laid down the ground rules for contributed ports:

Erik, thanks for letting us know. Always good to see someone expanding the WebRTC ecosystem!

Assuming the porting adheres to our style guidelines and our practices for platform-specific code, we can help land this. The only caveat is that we will not be able to fully support it through our trybots and tests. When the build breaks, you will need to fix.

Firefox 22 Hits Beta

On Tuesday, Firefox 21 was released, which leaves only one more version before WebRTC is enabled by default. Firefox 22 is currently scheduled for release on June 24. If you’re impatient, you can get a preview in Firefox Beta, Aurora, or if you’re really brave, Nightly.

Jon Fingas, writing for Engadget, has more on Firefox 22:

Though Mozilla has long been a proponent of WebRTC for plugin-free video and voice chat, it hasn’t been ready to enable the full protocol in Firefox as a matter of course. It’s more confident as of this week


Google IO

Justin Uberti and Sam Dutton wrapped up the week with a presentation on WebRTC at Google IO. Both the slides and the video are now available for your viewing pleasure.

Janko Roetgers covered the session highlights for GigaOm:

WebRTC, the new technology that enables plugin-free voice and video chat within the browser, should be available on more than one billion unique endpoints (think: desktop browsers and mobile devices) “within a week,” according to Google’s WebRTC engineering lead Justin Uberti.

Endpoints++

Last but not least, Tsahi Levent-Levi has a few suggestions for UC vendors and customers in our favorite post of the week:

All of the room systems and endpoints you are installing? Make them pure WebRTC capable – have them run an HTML5 browser and let Java Script do the rest. Have your own solution use that type of a deployment. All of your legacy products? Have a gateway for them to access the system.

+1 to that.

WebRTC Digest – Week of May 6

Here at vLine HQ, we have an internal mailing list that we use to share links to articles, mailing list posts, code checkins, and other interesting tidbits related to WebRTC.

Now that we finally have a blog, we thought it might be nice to share these links with you, dear reader (Hi Mom!). So, watch this space each Monday for a new, carefully-curated batch of week-old WebRTC news (how’s that for real-time?). With no further ado, here’s our first edition:

Exploding Endpoints and Spiders

Kelly Teal, writing for Channel Partners asks What in the World is WebRTC? and polls a few analysts for answers:

When it comes to video collaboration, everyone is talking about WebRTC. But what is WebRTC and what does it mean for partners?

 â€Š

“What WebRTC does do is create the potential for an explosion of browser-based video endpoints, which will only connect to other endpoints running the same standard,” Wainhouse Research analyst Bill Haskins told Channel Partners.

We certainly agree about the explosion of browser-based endpoints. Genband, however, disagreed that they will only talk to others running the same standard by announcing SPiDR, a new legacy-to-WebRTC gateway. Gary Audin, writing for NoJitter has the story:

SPiDR sits at the edge of the operator’s network. It provides open, web-centric APIs that allow application developers to produce rich communications services through the network including voice, video, presence, shared address book, call history, instant messaging, and collaboration. 

Google IO 411

Google’s annual developer shindig is coming to town later this week, and WebRTC Tech Lead Justin Uberti will be returning to the stage with another sure-to-be-packed-to-the-rafters session on our favorite real-time stack (in case you missed his session last year, you can check out the video here).

This year he’ll be co-presenting with Chrome Developer Advocate and HTML5 Rocks contributor Sam Dutton. The two will also be running a  hands-on Code Lab to help lucky ticket-holders translate the alphabet soup of WebRTC APIs and protocols into tasty web apps.

In this codelab, we’ll help you get to grips with the core APIs and technologies of WebRTC: – MediaStream (aka getUserMedia): what is it and how can I use it? – RTCPeerConnection: what is important about WebRTC’s most powerful API? – RTCDataChannel: how can I set up real-time communication of arbitrary data? – signalling: what is it and how do I set it up? – servers: what do I need for signalling, STUN, and TURN?

Bird Food

Speaking of tasty treats, Justin warmed up for IO by dishing out a trio of long-awaited morsels destined for Chrome Canary on the discuss-webrtc mailing list. On Wednesday, he hinted that reliable data channels are landing soon (if you want to be the first to know when they alight, you can star Issue 1493).

Then on Friday, he made our week by announcing that you’ll soon be able to use the getStats() API to discover which ICE candidates the browser selected. No more tcpdump or verbose logging to figure out if you’re using a relay server!!! Are you as excited as we are?

And last, but not least, he confirmed that Canary has gained the ability to load-balance across multiple TURN servers. Full thread here.

Richard Mentor Johnson?

Finally, we have a couple of codec-related tidbits. WebM Product Manager and former interim On2 CEO Matt Frost posted that VP9 is nearing completion. We don’t know what we’re more excited about, the support for depth channels (3D webcams + depth maps + WebGL = ???) or the VP9 vs H.265 codec wars.

Since it’s not seeming especially likely that the browser vendors are going to agree on a common built-in codec this decade, Mozilla’s push for an all-javascript codec is starting to sound more and more reasonable. Following up on Brendan Eich’s Today I Saw the Future post about ORBX.js , Peter Bright, wrote a nice piece for Ars Technica with more technical detail:

For browsers including Internet Explorer 10 and Safari on iOS, ORBX is used in I-frame-only mode. For other browsers, including Firefox and Chrome, it uses a more conventional mixed mode. That’s because the mixed mode depends on WebGL for part of its decoding. I-frames can be encoded entirely in JavaScript, but P-frames require the use of shader programs due to their greater complexity. Internet Explorer 10 and Safari on iOS don’t support WebGL, and so can’t be used to run shader programs. As a result, they use about twice as much bandwidth for the same level of video quality.

Sadly, no public demo yet. But we can’t wait to try it on our iPhone 12s.

Free vLine/WebRTC Consulting and Training

One of our biggest priorities is to make it as easy as possible to get started with WebRTC and the vLine platform. To that end, we’re giving away five free full-day consulting and training sessions to developers working on projects utilizing WebRTC and vLine that will go live by June 30.

For developers in the continental US, we will come to your office, sit down beside you and do whatever it takes to make your project successful. For those in other parts of the world, we’ll do the same thing via video chat and screen sharing.

If you’re interested, please send an email to [email protected] telling us what you’re building and how you would make use of the consulting time.

On May 10, we’ll review the requests and select the five developers. Priority will be given to projects where development resources have already been allocated and that will be launching soon.

We look forward to hearing from you!

vLine Just Got Easier

We’re happy to announce a major milestone for the vLine platform: You can now create a private-label video chat service in about a minute, without writing any code.

And to make it even easier to take the next step and integrate it with your website, we’re giving away five free full-day, on-site consulting and training sessions to qualifying projects (full details here).

To create your video chat service, go to vline.com and click the big ‘Get Started’ button. Or to see how it works, check out this video: