Posts Tagged WebRTC

Real-Time Communications Conference gets Real

rtc_thumbIt is only a few weeks until this year’s IIT Real-Time Communications Conference kicks off in Chicago, IL at the Illinois Institute of Technology.

I think it is going to be a great conference.  Of course, I’m slightly biased as I helped organize it again this year as a co-chair of the WebRTC and Cloud Communications Track.  I’m also an adjunct professor at IIT – I remote teach a WebRTC class there, using WebRTC, of course!

Here are some of the highlights for me:

  • “The Future of Open Source Software in Telecom” panel, moderated by Andy Abramson on the first day of the conference, Tuesday October 6, 2015 at 1pm.
  • “What’s Next for WebRTC” panel, moderated by Chad Hart of webrtcHacks on October 6, 2015 at 4:30pm.
  • “Simple secure federated identity for WebRTC (your new phone number)”, a presentation by the always interesting Tim Panton on Wednesday October 7, 2015 at 9am.
  • WebRTC and Federated Identity Tutorials on the day before the conference, Monday October 5, 2015 from 9am – 5pm.  Dan Burnett and I will give the WebRTC tutorial in the morning, and Matthew Hodgson from will give the identity tutorial in the afternoon.
  • TADHack-2015TADHack Mini Hackathon, the weekend before the conference, October 3 – 4, 2015.  These are so much fun, and I can’t wait to see what people come up with, especially some of my students…  Who will win the $8k in prizes?  Kudos to Alan Quayle for organizing these incredibly creative events.

Besides these highlights, I always find interesting things in the other tracks, including:

And don’t forget a keynote by Henning Schulzrinne, of SIP and FCC fame, on “5G: What can we learn from the previous four generations?” on Thursday, October 8, 2015 at 11am.

Check out the impressive list of speakers at this years event.

Will I see you there?


, , , , , , ,

Leave a comment

Third Edition of the WebRTC Book

WebRTC BookI am very proud of the Third Edition of the WebRTC Book that came out just a few weeks ago.  My co-author Dan and I have been working on it for months, and it is always exciting to launch a new edition!

We worked feverishly during the IETF-89 meeting in London to get all the updates finished – all the APIs, protocols, and standards referenced should be up to date as of then (first week in March).  We also had a lot of fun testing and doing screen captures of the new Demo Application, which now utilizes the WebRTC data channel for Real-Time Text (RTT) between the two browsers.  I’ll write another day about RTT and how much fun it is compared to normal texting or instant messaging in another post.  For us, to make use of the data channel APIs and protocols and show the interoperability between Chrome and Firefox browsers was a lot of fun as well.

16The Demo Application also can now utilize a TURN server for enhanced NAT traversal.  In some circumstances, NATs or firewalls will prevent a direct peer-to-peer Peer Connection from being established between two browsers, and a relay in the cloud is needed.  If the Demo Application fails for you, try reloading the page adding a ?turnuri=1 to the URL and see if it works for you!

Also new for this edition is a description of how to analyze WebRTC protocols on your computer using the excellent open source packet capture and analysis tool Wireshark.  Between Wireshark and various browser tools (try Tools/Developer Tools in Chrome and Tools/Web Developer in  Firefox, or chrome://webrtc-internals in Chrome for lots of useful WebRTC info), you can learn a lot just by playing with WebRTC.  If your application is not working, these tools allow you to debug and analyze what is happening.

Screen Shot 2014-04-02 at 3.40.26 PMFinally, Dan’s introduction to the WebRTC API has been greatly expanded with step-by-step introductions to the various functional parts of the client and server code.  As always, you can download all of our Demo Application code from our book website, and also see it running as well.

We have received so much excellent feedback in the one and a half years since we published the first edition.  We can’t wait to hear from you on what you think of the Third Edition.  We enjoy hearing from you on Twitter, Facebook, or Google+.

, , , , ,

Leave a comment

How to Communicate Securely over the Internet

Today, I published a new Internet-Draft on how to securely communicate over the Internet using a new web technology known as WebRTC and the ZRTP protocol.  Using this technique, Internet users can determine if the National Security Agency, or anyone else, is listening in to their calls placed using a web browser.  There are already a number of commercial and open source products utilizing ZRTP, including Silent CircleJitsi, and others, but this new technique opens it up for all web users.

The WebRTC Book

For those of you not involved in the VoIP or video conferencing world, WebRTC, or Web Real-Time Communications, is a new standards effort to add real-time voice and video communications capabilities to web browsers.  This allows web developers to add voice and video communications with a few standard JavaScript calls.  All the pieces needed to communicate, including codecs and the ability to traverse NAT and firewalls, are built into the browser.  Today, WebRTC is available in the Chrome and Firefox browsers, and in Chrome for Android.  I’ve written a book on WebRTC if you want to learn more about it.

With WebRTC, all media flows are encrypted and authenticated using Secure RTP or SRTP.  Unfortunately, the keying method chosen for WebRTC is DTLS-SRTP or Datagram Transport Layer Security for Secure Real-time Transport Protocol.  DTLS-SRTP on its own does not provide protection against Man-in-the-Middle (MitM) attacks, also known as eavesdropping attacks.    Today, the news is full of reasons why Internet users need such protection.  We now know the surveillance of Internet users is widespread.

The ZRTP security protocol, published as RFC 6189 back in 2011,  was invented by Phil Zimmermann to allow Internet users to communicate securely and privately over the Internet.   ZRTP was not selected as the default keying method for WebRTC, despite it being the ideal candidate.

However, ZRTP can still be used to provide MitM protection for WebRTC sessions established using DTLS-SRTP.  As described in the new Internet-Draft written by myself, Phil Zimmermann, Jon Callas, Travis Cross, and John Yoakum, ZRTP can be implemented in JavaScript and run in both browsers over the WebRTC data channel.  The ZRTP exchange is used to compare the DTLS-SRTP fingerprints used to establish the media flows.  If the fingerprints match, and the ZRTP exchange is authenticated by the users comparing the Short Authentication Strings (SAS) displayed on each browser, the WebRTC media sessions are free of MitM attackers.

Jitsi Short Authentication String

How does this work?  You’ll have to read the ZRTP specification to find out exactly how, but in simple technical terms,  it is because ZRTP uses a technique known as a Diffie-Hellman key exchange augmented with a hash commitment.  This allows the SAS, which can be two words or four hex digits, to prove that a media session has no eavesdroppers present.

We have documented this usage of ZRTP with WebRTC in the Internet-Draft document draft-johnston-webrtc-zrtp.  Hopefully soon there will be some open source ZRTP JavaScript libraries freely available for web developers.

Everyone needs privacy in their communication, and WebRTC with ZRTP finaly provides a real solution to all Internet users.

, , , , , ,


New WebRTC Certification and Training!

WebRTCIf you are involved in the real-time communications industry, there’s no doubt you’ve been hearing about, and investigating WebRTC – Web Real-Time Communications.  WebRTC is about adding a complete audio and video stack to browsers, and exposing these capabilities to web developers through JavaScript APIs.  WebRTC is going to make huge changes in our industry.

The WebRTC Book

I’ve been fortunate to be involved in WebRTC right from the beginning in the standards, and  with my friend Dan Burnett wrote the first book on WebRTC.   Perhaps you have read it?   Although it has been less than a year since we first published it, we recently published the second edition to track the increasing pace of development and innovation in WebRTC.

Now, we are pleased to announce online and in-person training and certification for WebRTC, in partnership with the WebRTC School.   We have put together two training classes:

CWICertified WebRTC Integrator – this is a course for architects, system integrators, and VoIP and telephony developers who want to integrate WebRTC communications from browsers into their existing VoIP and video conferencing infrastructure.  It details all the protocols needed and the principles behind architecting and designing gateways. This course is online right now at the WebRTC School!

CWDCertified WebRTC Developer – this course is for web developers, web architects, and web integrators who want to learn how to use the WebRTC JavaScript APIs to create WebRTC sites and applications.  It details all the W3C APIs and all the components needed to get WebRTC up and running, including signaling, servers, and security.  This course includes actual WebRTC code which runs on browsers today.  This course will available  online at the WebRTC School later this month.

We are very excited to be launching these training classes.  But what is the certification part?  Following its highly successful SIP School Certified Associate  (SSCA) program, WebRTC School is offering certification via online testing for Certified WebRTC Integrator (CWI) and Certified WebRTC Developer (CWD) programs.

I hope these classes will help spread the word on WebRTC!  If you take either of these classes, I’d love to hear from you what you think and what you have learned.


, , , , , , , , , ,

Leave a comment

WebRTC Book Giveaway!

WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web Book CoverWe’re giving away 10 copies of the WebRTC Book!  WebRTC is an exciting new technology coming to web browsers that allows any site to add real-time communication features and capabilities.  Just a few lines of JavaScript is needed to add Skype-like capabilities, and all without any downloads, plugins, or Flash!  Find out why so many people are excited about WebRTC: contact centers, service providers, VoIP providers, OTT providers, and ordinary web site owners.

goodreadsThe giveaway is hosted by goodreads, the social reading site.  If you love to read but haven’t found Goodreads, you should check it out!

From now until November 9, you can sign up to win a paperback copy.  Winners notified on November 10.

Good luck!

, , , ,

Leave a comment

Following WebRTC

WebRTC, Web Real-Time Communications, is a fast moving topic these days!  Here are a few of my suggestions for how to keep up.

First a note about terminology.  Although Google named their open source project webrtc, WebRTC is not just a Google project, it is a major industry initiative involving open Internet standards being developed by many participants.  Don’t confuse these two!

1. Follow Browser Announcements and Releases

Google and Mozilla are the browsers most actively implementing WebRTC today.  WebRTC is available in Google Chrome Beta browser. Download and give it a try for the latest WebRTC extensions.  Some future WebRTC capabilities may be in Google’s Chrome Canary which is the developers preview version of the browser.  To experiment with Mozilla Firefox, you will need to use their nightly build.  Microsoft Internet Explorer and Apple Safari don’t yet have anything available, but you can track their future announcements here and here.

2. Follow the Standards

WebRTC is not just about browser deployments, it is about standard APIs and standard protocols.  To really follow what is going on in WebRTC, you need to track the standards being developed in the W3C and IETF.  This can be a bit tricky, but if you start with the W3C WEBRTC Working Group and the IETF RTCWEB Working Group, that is a good start.

If you have an eReader, try this out.  Here is a link to download the entire set of RTCWEB IETF Internet-Drafts in EPUB format  and here is the set in MOBI format.    Various other sets of IETF documents and RFCs is also available at  The conversion is done using a script written by Tero Kivinen – nice  job!  The formatting of the ASCII art is not 100%, but this is a difficult problem.  The MOBI format worked better for me than the EPUB version, but YMMV.  Perhaps one day the IETF will adopt a friendlier format for Internet-Drafts and RFCs, but I’m not holding my breath!

3. Try WebRTC sites and applications

There are a number of sites and applications already taking advantage of WebRTC features.  One of my favorites is FrisB, a cool new way to think about browser to PSTN communication.  You can find plenty of others by searching the web.  Also, many developers announce and discuss their WebRTC projects on Twitter, so searching with the #webrtc hashtag can find lots of cool things.

There are some interesting blogs out there on WebRTC, including a blog by Tsahi Levent-Levi.

WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web Book CoverFor background on WebRTC, there are some decent resources.  You might enjoy this video presentation by one of the editors of the W3C WebRTC specification, Cullen Jennings.  If you like books, you might like “WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web”  written by myself and Dan Burnett, also a co-author of the main WebRTC spec and also the Media Capture and Streams specification.

Best of luck in following WebRTC!  Feel free to share your own favorite ways and links to follow this work.

, , , , , , ,

Leave a comment

WebRTC Interoperability

I’ve spent many years of my career working on interoperability in communication systems.  Back in the dark ages, I did SS7 interoperability testing.  During my CLEC days, I ran a test lab that tested optical, telephony, and ATM/Frame Relay equipment.  I’ve spent many years working on interoperability issues with SIP, starting with the SIP call flows (RFC 3665 and RFC 3666) and then SDP Offer answer (RFC 4317).  I’ve also been to many SIPits (SIP interoperability events run by the SIP Forum), testing voice and video interoperability.

WebRTC poses some interesting interoperability challenges, but I am hopeful we will get it right.

There are four different areas of interoperability: browser, protocol, codec, and offer/answer. Lets go through them one by one.

Browser interoperability is about aWebRTC application or site working the same regardless of which browser the user is using.  In the past browser interoperability was just a browser/server issue, but with the peer-to-peer media and data channel flows of WebRTC, this is now a browser/browser issue.  The good news is that there are only a handful of browsers, so the interop  matrix is not too large.  The bad news is that there are signs of discord already in pre-standards implementations.  For one thing, all browsers must utilize the same APIs, or else WebRTC will be a major headache for developers.  Of course, libraries can hide this complexity from developers, but this will slow down deployment and produces some needlessly bad user experiences.  If we see one browser vendor using their own APIs instead of using the standard ones from the W3C, then we will know that someone is playing company games at the expense of the Internet users of the world.  Hopefully this won’t happen, but it if does, users will and developers will likely move away from that browser.

Protocol interoperability is a major concern for WebRTC.  In the past, browsers didn’t implement many protocols – everything used HTTP (Hyper-Text Transport Protocol).  Today, browsers are doing more, including WebSockets, and will soon move to the next version of HTTP, 2.0.  With WebRTC, the browser RTC Function has to implement multiple protocols including RTP, ICE, STUN, TURN, SCTP etc.  These protocols define “bits on the wire” and “state machines” that ensure that interoperability works.  For browser-to-browser media and data channels to work, browsers must implement these protocols and carefully follow the standards.  If they don’t the whole industry will suffer.  There are some issues today with the pre-standard WebRTC browser implementations.  For example, one browser today implements a proprietary STUN client that will not work with standard STUN servers.   Browser vendors will need to take protocol interoperability very seriously, and recognize that this is something new for them and that they need to follow industry best practices and approaches.

Codec interoperability is about ensuring that media sessions don’t fail because there is no common codec supported on both ends of the session.  There are so many codecs in use, and every vendor and service provider seems to have their own favorite one.  Fortunately, we should be able to avoid this for audio codecs.  The IETF has recently finalized the Opus audio codec for speech and music, published as RFC 6717 this month.  It really is a fantastic codec, much better than all the rest, making it an easy choice as one mandatory to implement (MTI) codec for WebRTC. Opus is also available as open source.   The other MTI codec is G.711, also known as PCM, which provides interoperability in the VoIP and telephony world, and is also needed for interworking with the telephone network.  Video codec choice is much more difficult.  While H.264 is widely used today, there are no open source implementations or royalty-free licensing available for browsers or implementors.  As such, it is very difficult to see how it could be chosen as a MTI video codec.  Google’s VP8 video codec is proposed as an alternative, and is available in open source.  However, there is much uncertainty about the licensing status of VP8.  Should WebRTC deploy without common video codecs, this again could result in interoperability delays.

Offer/answer interoperability is perhaps the least understood, but most important area.  Offer/answer refers to the negotiation of codecs, parameters, and settings for the media session or data channel between the two browsers.  Even if both browsers use common APIs, standard protocols, and common codecs, if they are unable to successfully negotiate and configure their media or data channel, the connection will fail.  WebRTC uses Session Description Protocol (SDP) to do this offer/answer exchange.  The pre-standard WebRTC implementations are, frankly, a mess in this area.  Their SDP is not standard, and not interoperable with anything else. It will take a lot of work to get this right, and we all must insist that browser vendors support standard offer/answer negotiations.

Occasionally, it is suggested that perhaps offer/answer would be easier if we didn’t use SDP.  We all know and hate SDP, and it is ugly and awkward to use.  However, it has taken over a decade’s work and experience to make it work, and any replacement would likely take that many years to get to work.  And, in addition, since much of the standards-based VoIP and video world uses SDP, it would need to map to SDP as well.  I can’t see this helping interoperability in any way.  Previous efforts to replace SDP failed (anyone remember SDPng?) and I think anyone advocating replacing SDP needs to explain why a new effort wouldn’t meet a similar end, and why this effort wouldn’t take a decade.  Also, the complexities of offer/answer relate to the complexities of negotiating an end-to-end session, and the actual syntax of the descriptions are a very small part of the complexity.

So WebRTC definitely has some interoperability challenges ahead of it.  Fortunately, there are

WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web Book Cover

WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web

many experienced engineers who are participating and helping with the effort.  As long as the browser vendors take this seriously and don’t play games, I think WebRTC will have good interoperability, which will benefit web developers and web users alike.

If you are interested in WebRTC, you might like my new book “WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web” published this month by Digital Codex LLC.

, , , , ,