BlogGeekMe WebRTC Interviews Vol 1 201504

10 Interviews
Inspiring WebRTC
Tsahi Levent-Levi
tsahil@bloggeek.me
Tsahi Levent-Levi
10 Inspiring WebRTC Interviews
Table of Contents
Introduction........................................................................................................................................................... 2
1.
Google: Serge Lachapelle .............................................................................................................................. 3
2.
TokBox: Ian Small ......................................................................................................................................... 5
3.
Talko: Matt Pope and Richard Speyer ......................................................................................................... 10
4.
LiveNinja: Emilio Cueto ............................................................................................................................... 15
5.
Togetheroo: Bart Yeary............................................................................................................................... 18
6.
Jocly: Michel Gutierrez ............................................................................................................................... 22
7.
Jitsi: Emil Ivov ............................................................................................................................................. 27
8.
CallStats.io: Varun Singh ............................................................................................................................. 33
9.
Peer5: Hadar Weiss..................................................................................................................................... 37
10.
Lantern: Adam Fisk ..................................................................................................................................... 40
Appendix A: Finding out More ............................................................................................................................. 44
2015 BlogGeek.me All Rights Reserved
Tsahi Levent-Levi
Introduction
I have been running interviews with entrepreneurs making use of WebRTC since 2012.
There are already over 60 WebRTC interviews on BlogGeek.me and growing.
I decided to curate 10 inspiring interviews out of that collection and provide them as a
single ebook something you can read in long form format. The idea? Get your juices
going around the endless possibilities open to you with WebRTC.
So find a comfortable place to sit down and pick the interviews that most interest you
Ive enjoyed all of them!
What stories will you find here?

1
Google -
How Google sees the uptake of WebRTC by developers
TokBox -
Delivering a video communication platform to any developer
Talko -
Reinventing group conversations
LiveNinja -
Marketplaces and click-to-call wrapped in one company
Togetheroo -
Gaming? Social? Video calling? Adaptablox has it all in a very

interesting package
Jocly -
Board gaming meets WebRTC, on a shoestring budget
Jitsi -
From VoIP Client to server side SFU
CallStats.io -
Monitoring WebRTC deployments
Peer5 -
Serverless CDN for distributed content delivery
10
Lantern -
Ending censorship, P2P-style
Tsahi Levent-Levi
1. Google: Serge Lachapelle

August 2012
While one of the first interviews, it is also an important one: Google have been the most
instrumental company when it comes to WebRTC, so the opinions of Serge Lachapelle,
the Product Manager that leads WebRTC in Google, are a window into everything
WebRTC.
Serge Lachapelle is the guy in charge of WebRTC at

Google these days. In 1997, Serge co-founded Marratech,
a multi user video conferencing software company.
Marratech was acquired by Google in 2007 where Serge
currently works as Product Manager. At Google, Serge
launched Gmail video chat, lead the initial work to build a
multi user solution (now Google+ Hangouts) and
completed the acquisition of Global IP Solutions (GIPS). This acquisition lead to the
creation of webrtc.org, his current project. I guess he is one of the main decision makers
when it comes to WebRTC.
Here is a quick Q&A that I did with Serge enjoy!
What is the most compelling service or demo youve seen done on top of
WebRTC? Something that didnt cross your mind when you started off with
WebRTC at Google.
All the games, augmented reality and the gesture tracking have really surprised the
whole team.
Where do you think WebRTC will have the most impact? Is it pure VoIP? video
conferencing? OTT players in the telco market? Someplace else?
I think the main impact will be to naturally bring in human conversation in normal every
day scenarios without having to go to a specific app. Think of it as being able to drop
in a real time voice / video conversation in any web app and make it look and feel as
natural as a text input field.
Tsahi Levent-Levi
What I see today is startup companies playing with and adopting WebRTC
wholeheartedly and on the other hand, the large players of the industry looking
into it companies like AT&T and Cisco. Where are all the mid-sized and even
large companies? Why arent they doing anything interesting with WebRTC?
WebRTC can impact all sizes of companies and were excited to see companies like
Voxeo a great example of a medium company executing with WebRTC projects.
Youve taken a strategy of desktop first with WebRTC, where in todays world the
tendency is to go mobile first. Why is that?
One reason is that the WebRTC API has undergone several changes at the W3C and
IETF. We decided to use the desktop as an implementation reference to iterate quickly
in development of the standard. Mobile possibilities for WebRTC are incredible!
I understood that Google Talk, Google Voice and Google+ Hangout are planned to
be converged into a single service or platform if you will. I assume that they will
be using WebRTC for that. How are you going to solve the scalable video coding
issue for Hangout while that happens?
WebRTC is still a very new platform it has not fully launched :). Our goal is to create
an open web platform that has a quality standard so high that any system will be able to
adopt it without compromise. First step: launching the basic platform and getting it solid
and stable.
Anything else youd like my readers to be aware of? Other resources that people
interested in WebRTC should be following?
+webrtc on google+ is a good resource. Our discuss list on Google groups as well and
the IETF WebRTC mailing list. All linked from webrtc.org homepage.
Tsahi Levent-Levi
2. TokBox: Ian Small

August 2013
Ian Small was the CEO of TokBox at the time of the interview. It was also after
Telefnica acquired TokBox. The end result? TokBox is part of Telefnica Digitals
communications division, which Ian Small now leads, and TokBox I allowed to stay
rather independent from the large mothership that is Telefnica.
This one is a doozy. There have been several acquisitions

in the area of WebRTC. The most important one is the
acquisition of TokBox by Telefonica Digital, which for me is
a vote of confidence from a telco that this technology
matters.
During WebRTC Conference & Expo, I caught up with Ian
Small, CEO of TokBox, and asked him for an interview. I
was more than happy when he obliged. Here are my
questions and his answers.
What is TokBox all about?

TokBox operates a global WebRTC video platform and provides the tools for developers
and enterprises to quickly and easily build live video communications into online and
mobile commercial applications. Customers use our platform to power pre- and postsales customer service, sports and entertainment experiences, brand advertising, and
education services. TokBoxs OpenTok Platform provides everything you need to
deploy scalable, bandwidth efficient WebRTC video communications for your business.
Tsahi Levent-Levi
You are part of Telefnica now. Has that changed anything for you guys (besides
the financial backing)?
Telefnica has been establishing a good track record of acquiring innovative technology
companies while giving them the freedom and room they need to flourish. At a
technical level, weve been able to take advantage of some of Telefnicas in-depth
understanding of networks, real-time QOS and mobile connectivity. But more
importantly, having access to Telefnicas global infrastructure and scale has further
reinforced our ability to provide enterprise-grade service and has accelerated our ability
to innovate around the WebRTC standard. As more enterprises are embracing video
communications as part of their business and service offering, particularly around
WebRTC, this infrastructure, scale and speed is increasingly critical.
I am interested to know what value does Telefnica see in WebRTC and a video
API platform?
Telefnica Digital (the innovation arm of Telefnica) has a mission to put digital at the
core of the company. WebRTC, and video generally, are becoming a major part of the
digital communications world, so it makes sense for Telefnica Digital to have a major
beachhead in the future of digital communications, and to want to incorporate OpenTokbased applications into broader areas of the business. Telefnica has really embraced
our level of innovation and the Silicon Valley thinking we bring to the business.
You started off as a Flash based API company. What made you switch your focus
to WebRTC?
From the very beginning, we designed OpenTok to be protocol-neutral, because we
believed that a then-undefined browser standard would eventually supersede
Flash. Now that WebRTC is here, it has a wide range of advantages over Flash,
starting with increased audio and video quality. For more than a year, we have focused
almost all of our energy on the new standard a focus that is now being rewarded with
the expanding distribution and access to WebRTC. With WebRTC now natively part of
Chrome and Firefox, and our bridging capability for other browsers as well as mobile
devices, it is now a globally viable solution.
Tsahi Levent-Levi
Where do you see Flash within your solution?

OpenTok supports both WebRTC and Flash implementations in a way that is
transparent to the developer. Until Mozillas introduction of WebRTC support in Firefox
just as WebRTC Expo got under way, Flash was more ubiquitous than WebRTC, but
that is now changing quickly in the broad consumer marketplace. While we expect to
support both platforms for the foreseeable future, our energies are focused on WebRTC
with a clear expectation that it will supersede Flash completely.
What do you use for signaling?

We use a proprietary state-of-the-art messaging fabric called Rumor for
signaling. Rumor was designed based on our experience with the wide variety of
customer use cases we have seen across our Flash and WebRTC platforms over the
last 3 years. Our experience was that trying to adapt existing protocols (XMPP, SIP,
etc.) to the task didnt deliver the flexibility and performance our customers needed;
other platform companies in adjacent spaces have found this to be true as well. Rumor
supports a variety of endpoints and is fully HTML5 compliant, so any modern browser
with web socket support can take advantage of Rumor through our OpenTok
platform. You can read more about Rumor on our blog post from about a year ago.
Why did we call our signaling infrastructure Rumor? Because, of
course, nothing travels faster than a rumor
The Cloud Raptor SDK, which we just introduced at WebRTC Expo, integrates a server
application directly into the OpenTok cloud by connecting directly to the Rumor
messaging fabric (you can find more information on Cloud Raptor on our blog).
Tsahi Levent-Levi
Can you tell me a bit about the technologies you selected for your back end?
To make OpenTok an enterprise-grade, WebRTC-native service at the browser level,
and in the cloud most of what we need to do is pretty bleeding-edge. The core of our
cloud is based on three scalable WebRTC-native components: Mantis, Rumor and
Symphony. We brought Mantis out into the open a couple of months ago. Mantis is our
cloud-based WebRTC media scaler, which routes, scales and shapes WebRTC traffic,
and was custom-developed in-house. You canread more about Mantis design on our
bog.
In addition to Rumor (discussed more above), we also have a custom-built WebRTC
session coordination server called Symphony which coordinates our distributed
WebRTC cloud. We havent talked about Symphony before, so I guess your Q&A is its
coming-out party! Internally, we use WebRTC compliant protocols such as RTP/RTCP
for media and control. We distribute Mantis, Rumor and Symphony services in data
centers around the globe, and operate it as one cloud.
You started off as a pure video API company, and now it seems that with your
new offerings you are trying to provide a more complete solution. Any reason for
that shift?
We are focused on providing all the pieces that a developer requires to build and
manage the video communications component of a commercial application. Weve had
APIs, widgets, plug-ins, SDKs. Whatever makes life faster and simpler for a developer
is what well provide.
When you added WebRTC into your existing platform what challenges did you
face?
On the web side, we wanted our clients to be fully HTML5 compliant. This entailed
adapting our signaling infrastructure to run over web-sockets so it could be as fast and
highly performing as possible. In addition, we also wanted to interoperate with endpoints
that had no native WebRTC support such as iOS devices, so that required building
custom SDK libraries for those devices. Last, the WebRTC standard doesnt include the
end-to-end functionality needed to deliver real-world use cases. We built out a powerful
cloud WebRTC infrastructure that provides value added services such as multi-party,
intelligent adaptation to varying network conditions and enables scale.
Tsahi Levent-Levi
Given the opportunity, what would you change in WebRTC?

WebRTC is a really great step forward for the browser world. But there are still some
shortcomings in the standard, some of which will likely get resolved as real-world
experience with WebRTC grows, and some of which reflect agendas of the key drivers
of the standard. Top of mind real-world issues include things like temporal scalability
support for video and discontinuous transmission of audio. And of course, the codec
wars have very real implications for power-efficiency in mobile devices as well as
narrowing the range of low-end devices that can use standards-compliant WebRTC
optional H.264 support would make a big difference to mobile penetration and usage.
Whats next for TokBox?

As much as weve gotten done to date, we feel like theres a huge amount of road still
ahead of us and of the industry. We will continue to augment our underlying WebRTC
capability with the enterprise infrastructure and tools that enable our customers and
partners to deliver compelling, real-time video experiences online and in their mobile
applications. There are more advances to be made in traffic scaling and shaping for
improved audio and video quality, and we will deliver more use-case specific solutions
like OpenTok for Customer Service, the pre-configured set of tools and components that
makes it faster and easier to implement video for customer service applications. Were
looking forward to continuing to set the pace for native WebRTC cloud infrastructure,
and to seeing face-to-face video become an everyday part of your application
experience.
Tsahi Levent-Levi
3. Talko: Matt Pope and Richard Speyer

January 2015
Talko is a high profile startup that have been working in stealth mode since 2012. They
selected WebRTC from the beginning to deliver a mobile first service. The decision
making processes they went through and the type of experience they are striving for is
what makes their story so interesting.
There have been several high profile

communication startups lately that
launched their service. What they all
have in common is the fact that they
make use of WebRTC and indicate it as
one of the technical benefits they have.
One of these vendors is Talko, which
focus on mobile team communications.
It was a pleasure for me to have a chat with Matt Pope, Co-founder & Product Lead at
Talko, and Richard Speyer, Software Engineer at Talko. I really enjoyed this talk we
had, as it validated a lot of the assumptions I had about why and how vendors adopt
WebRTC into their technology stack.
Heres what Matt and Richard had to share with you in this interview we had.
What is Talko all about?

Talko is an app for mobile team communications. We designed Talko for todays new
style of work anytime, anywhere, while mobile and on the go.
The smartphone has forever changed how we live and work, keeping us connected, no
matter where we are. But although were connecting 10x more, were saying 10x
less. The result is lost time and diminished productivity. Talko brings people together
to user their voices to get things done. Because Talko is designed for your eyes, ears
and voice not just your thumbs, users are able to unlock the potential of voice and
greatly improve and enhance the (formerly) dreaded conference call through various
features, including:
10
Tsahi Levent-Levi
11
Talk LIVE or not: Talk when and how you want, LIVE or not, so you maximize
team productivity and minimize disruption. If theres a team call and someone
cant be there, no problem they can listen and reply to the whole conversation,
or just the important moments, when they free up.
Show while you talk: Tap the camera as you speak and others will instantly see
what you see at the moment. Theres no disruption to the flow of the
conversation.
One-tap team conferencing: Theres no need to waste time setting up

conference bridges or remembering passcodes. Tap your team to ring in Talko
its that simple.
Any network, no network: Mobile networks can be spotty its sad but true.
Whether online (WiFi or cell) or offline in Talko, it doesnt matter. Keep talking
and it will just go when your device reconnects. No need to ever Try Again
later.
Find, replay and share: Calls neednt require tedious note-taking and email
follow-up to get everyone on the same page. Recorded voice in Talko lets you
organize, find, replay and share important conversations and key moments using
flags, tags and bookmarks.
Tsahi Levent-Levi
What was the reason you chose to use WebRTC in a mobile app?
We decided to bet on WebRTC in early 2012, just as we were beginning product
development. While the answer at that time was far less obvious than it would be now,
there were several factors that played into our decision at that time and that have
proven to be tremendously beneficial:
Open source: We were able to stand on the shoulders of some amazing work
that had been done by those in the open source community. When youre a small
team like us, its necessary to be really thoughtful about where you need to build
unique, differentiating technology and where it makes obvious sense to work with
the community. Many companies have open-sourced their WebRTC
implementation at Talko, we forked Googles.
Cross-Platform: When we first started working with WebRTC, we had to

develop our own custom support for building on iOS. But today, WebRTC is
written in C and C++, allowing us to cross compile the codebase across both iOS
and Android. This allows us to manage a single codebase for both platforms.
VoIP: WebRTC is built upon the latest and greatest in VoIP and real-time media,
which is crucial for Talko and the scenarios we enable, including allowing users
to communicate both LIVE and not LIVE, with seamless transitions between the
two.
What excites you about working in WebRTC?

WebRTC is a true best-in-class VoIP stack. It is available open source and has an
amazingly active development community. For a startup, we didnt want, nor did we
have the capacity, to build our own VoIP stack. Thanks to WebRTC we didnt need to.
This has allowed us to focus more of our engineering team on building the capabilities
that truly make Talko unique.
The ICE protocol is crucial to successful establishment of a RTP media connection,
especially when on a mobile device where the client is often on a 4G/LTE connection
and sitting behind multiple NAT devices. It is also extremely helpful in managing
networks coming and going, for example when a user walks out of their house and
needs to transition from WiFi to 4G/LTE.
12
Tsahi Levent-Levi
The Opus audio codec is a critical piece to delivering the high quality audio experience
that our users have come to expect in Talko. It allows us to send audio at a very high
bitrate and sample rate without consuming all of a users available bandwidth, and its
FEC algorithms allow us to seamlessly conceal the inevitable packet losses, which will
occur on any mobile Internet connection.
What signaling have you decided to integrate on top of WebRTC?

We use SIP as our signaling protocol currently. While not the most popular option these
days, it has the benefit of being one of the most well-supported and tried-and-true
signaling protocols out there.
Backend. What technologies and architecture are you using there?

Our service is deployed on a mix of AWS and Azure. All clients connect to a session
server which is fully custom code built in Erlang and manages a majority of the clients
server interaction, including registration, account management, and posting texts and
photos. When a user enters a call, we dynamically assign a media server for that call
session which all clients will connect to for live interaction.
The backend media servers are based on the open-source FreeSWITCH telephony
platform, which we adapted and customized based on our scenarios and learnings over
the last few years at this stage, a majority of the pipeline is running custom code.
Where do you see WebRTC going in 2-5 years?

We expect WebRTC and the forthcoming ORTC to continue to grow in their usages
and availability across all platforms. We hope to see adoption of the native APIs
specifically on mobile devices, continue to grow. Additionally, we hope to see
optimizations for the unique challenges of running a VoIP stack on a mobile phone,
such as: limited battery and CPU, the need to integrate with native audio APIs, and
efficient and adaptive handling of network interface switching and network quality
variation.
13
Tsahi Levent-Levi
If you had one piece of advice for those thinking of adopting WebRTC, what
would it be?
Theres a good amount of detail on this in our recent blog post, but for those already in
the VoIP/live media space we think that adopting WebRTC is a no-brainer. It represents
not only the latest technology, but also the greatest technology. It is a true best-in-class
VoIP platform, and it is free. Rather than managing your own VoIP stack, you can rely
on WebRTC and focus on building out your application logic.

There are certain modifications that we have made to the native API which we would
love to see make their way into the WebRTC standard and the API for all platforms.
One of these is the ability to be notified whenever the CSRC list in an RTP stream
changes. This is data which WebRTC has at the lower levels, and surfacing it to the
developers would allow them to expose rich information about who is talking and
contributing to a stream at any given time.
Whats next for Talko?

We are currently in the process of developing both Android and Web-based versions of
Talko, so keep an eye (and ear) out for that. Were also in the midst of localizing Talko
in about a dozen different languages weve heard the demand and are excited to bring
Talko to many more parts of the world!
14
Tsahi Levent-Levi
4. LiveNinja: Emilio Cueto

August 2014
On one hand, LiveNinja seems like a straightforward use case just use a WebRTC
PaaS and youre done. But as so often happens, the plot thickens. LiveNinja decided
down the road to migrate from a WebRTC PaaS vendor into building their own
communications infrastructure. Heres why.
LiveNinja is one of these companies that Ive been

following from afar for quite some time. Probably since I
began monitoring WebRTC. At the time, they used Flash,
but since then, like many others they have shifted towards
WebRTC.
I had an interesting chat with Emilio Cueto, CTO and CoFounder at LiveNinja about their new service Katana. I
wanted to share that conversation with you here.
What is LiveNinja all about?

LiveNinja is about creating and sharing in unique experiences that add value to your
personal and professional life. We offer our community of experts a way to monetize
their knowledge and provide our users with an outlet to learn new skills by using a realtime, fully immersive platform. Its all about making others instantly accessible to you in
a way that is mutually beneficial. This face-to-face, intimate experience is impossible to
achieve using any other real-time communication tool and something that other chat
services do not take into account.
You started a new service called Katana. Can you tell me a bit more about it?
Katana is an extension of LiveNinja as it focuses on experiences, but specifically for
businesses. Katana allows businesses to engage with their customers in a more human
way by giving online visitors a direct line of communication to a brands
representative. We provide companies with all the tools they need to more effectively
interact with their customers directly on their website. With a click of a button, a
customer can get the help they need, while still remaining active on the site. Weve
found that face-to-face communication improves the customer experience and positively
affects conversions and brand loyalty.
15
Tsahi Levent-Levi
You have gone off and decided to build Katana from the ground up. Why was
that?
At LiveNinja, we pride ourselves in thinking outside the box. The question is never can
we do this?, but rather how can we do this?. With Katana, we have a very long list of
features listed in our pipeline. We had to be sure we would be able to get through this
list (and account for any other features that came up), without having to rely on any
external dependencies. The only way to truly do that is to build it yourself!

We decided SIP was the best option for various reasons. One of the things that is so
great about Katana is that you can start a call on the Web, transfer to another device,
and even transfer to a traditional PSTN line such as your home or cell phone. We saw a
gap between web communication and traditional endpoints in a clean user interface. In
order to bridge the gap, it made perfect sense to use SIP, as it has been tried, tested,
and widely used for many years.

All users are assigned an extension and registered to a pbx. This allows us to perform
many of the same interactions users are already accustomed to with traditional
telephony. We handle media via an in-house MCU stack which can scale up/down as
needed. Because of this, we are able to handle calls (and negotiate different codecs)
not only from a traditional website, but also from many other devices, including sip
clients or even incoming PSTN calls. It opens up new opportunities for cool features to
be developed and deployed.
16
Tsahi Levent-Levi

I think we will continue to see more development in the space and will definitely come
across more interesting use cases. I think most people familiar with the tech can agree
that RTC is the future. The discussions between ORTC vs WebRTC will eventually be
ironed out (and probably merged in the long-term). RTC is here to stay and will
continue to grow into mainstream. You can already see interesting projects arising all
over github and the web in general. Id like to see someone dedicate time to perfecting
an RTC version of the SMPTE time format. That would be cool and totally disrupt the
audio recording/film editing industry!
would it be?
Dont just build another video chat application. Building a video chat application with
WebRTC is the equivalent of a Hello World app in my eyes. Think of what it is you
want to accomplish and how WebRTC can help you get there. What are you trying to
solve? What kind of experience are you looking to create for your potential users? Let
WebRTC be the stepping-stone that helps you build out your idea. WebRTC is only a
part of the big picture, not what you are selling.

Im not sure what Id change about WebRTC itself, but I would definitely like to see more
standardization across browsers. For example, the permissions prompt varies across
not only each browser, but each OS as well. This is simply a result of developing on
something that is not fully mature yet, though its getting closer. The more we develop
and use this technology commercially, the more we can push the envelope forward and
force these types of standardization to become possible.
Whats next for LiveNinja and Katana?
Were excited by the seemingly endless possibilities the future holds. We are going to
be completely rebuilding the LiveNinja marketplace, with Katanas technology at its
core. This will come along with a complete redesign of LiveNinja.com and bring the
same type of intercommunication between devices to each LiveNinja experience. This,
along with the many other features we have in our pipeline, definitely makes it an
exciting time for us!
17
Tsahi Levent-Levi
5. Togetheroo: Bart Yeary

November 2014
Togetheroo caught me off guard when I saw it. It had an interesting mix of video chat
and gaming for family interactions. Ive been in the video conferencing industry for
years, but this one didnt seem obvious to me. Since the interview, the company has
changed its name, which is why the interview is with Adaptablox while the introduction
and title are about Togetheroo.
This whole notion of WebRTC-for-gaming is quite

frustrating. Theres very little of it still.
When Bart Yeary, Chief Product Officer ofResonant
Games introduced me toAdapatablox, I was immediately
fascinated. To me, Adaptablox looks like a free-form game
to play with kids online and remotely. My only gripe is that
the letters on the blox arent in Hebrew.
Anyway, Bart was kind enough to share his experience
and views regarding the use he made of WebRTC for
Adaptablox.
What is Adaptablox all about?

The Adaptablox concept was born out of a need to create a better video chat
experience for kids and their distant relatives. We provide a solution to meet the needs
of distributed families with young children by adding context to their long distance
conversations. Family members join an Adaptablox video chat via a unique web
address and instantly begin to share interactive content in real-time. Each participant
shows up as a video inside of a circle with a pointer to indicate their cursor position.
They can see each others movements and synchronously interact with content like
educational games, toys and books. Currently the site provides a set of ABC blocks that
can be dragged & dropped to collaboratively spell words but ultimately the app will host
a series of puzzles, interactive books and learning games.
18
Tsahi Levent-Levi
Where did the idea come from?

My studio, Resonant Games, has been developing synchronous social games and
virtual worlds for the past 15 years. Back in 1999 we launched the first browser based
virtual world atFaketown.com. We specialize in building lightweight, highly accessible
yet immersing experiences that enable people to interact and share content in real-time.
When I became a dad I worried because our sons nearest relatives were over 500
miles away and I wanted his grandparents to share in his early development. I began
thinking of ways that we could leverage real-time technology to bring our family closer
together with more meaningful shared experiences. Clearly, video chat is more
rewarding than a phone call but the average grandparent doesnt have the confidence
to download and configure an application. Moreover, many young kids lack the patience
to stay focused during a video call and as a result they get distracted instead of focusing
on the conversation. When we discovered WebRTC we realized that we could create an
instant video chat layer on top of our synchronous content to create an immersing yet
accessible app specifically for distributed families with young children.
You started from the desktop. When will we see a mobile version?
Adaptablox is being built with an emphasis on accessibility. It is our goal to enable
families to safely connect in a shared virtual space without any friction or specific
hardware requirements. As such we intend to continue developing the core of our
product for the browser while iterating on a native mobile/tablet extension that is
interoperable with that experience.
Why use WebRTC for such a service?

WebRTC enables plugin free video chat that is much more accessible than
downloadable solutions. Statistics show that 75% of grandparents are comfortable
browsing the web (US Census Bureau 2014, American Community Survey) but only
12% are using Skype. Nonetheless, 11% of grandparents say that Skype is their
preferred method of staying in touch with their grandkids (MetLife: Grandparents
Investing in Grandchildren). Because we can embed WebRTC video chat directly on top
of synchronously interactive content we can merge video conversations with shared
books, toys and educational games without the need for a plugin.
19
Tsahi Levent-Levi

WebRTC brings the magic of video chat and synchronous play to less technically savvy
grandparents and kids. It allows us to keep the focus on a seamless shared experience
rather than forcing the end user through a frustrating on-boarding process or software
configuration. WebRTC also enables us to develop for both web and mobile apps so
that our virtual family HUB is accessible across all devices and platforms.

Weve been very happy with the realtime syncing service provided by Firebase.

We built our backend in Ruby on Rails, and currently host it at Heroku. Adaptablox will
eventually be a platform that artists and developers can build upon, so weve designed
the architecture around RESTful principles which will be easy to generalize into an API
when the time comes.

We are hopeful that all major browsers will incorporate support for WebRTC. We
believe that synchronous applications will become much easier to develop in the coming
years and as a result the refinement of the user experience and the content provided in
a real-time context will be the main differentiators.
would it be?
When developing your MVP it makes sense to leverage services like TokBox to
experiment with WebRTC. In general, we believe that the path of least resistance is the
best approach to building new products. If we believed that OpenTok couldnt provide
the stability or features that we needed we might consider another solution but so far we
have been pleased with their service.
20
Tsahi Levent-Levi
Whats next for Adaptablox?

We intend to offer vanity URLs for easier sharing and password protection for more
secure family spaces. Our team is currently creating a framework for developing
educational games that we will ultimately open up to 3rd party studios and we also have
a series of interactive books that we are designing internally. Finally, we intend to
deploy a subscription service to provide access to premium content that can be shared
during Adaptablox video calls.
21
Tsahi Levent-Levi
6. Jocly: Michel Gutierrez

November 2013
Jocly is another gaming company. What fascinated me here is that Michel Gutierrez has
built it with another developer on a shoestring budget, deciding to operate it without any
external funding. It is also the first real gaming vendor Ive seen that decided to make
use of WebRTC and not just a demo.
I dont know about you, but people always say how great
WebRTC is for the gaming industry. And yet, while we have
a gazillion vendors doing plain-old-video-conferencing,
there are no gaming vendors out there. Or at least there
werent.
Jocly is the first vendor to go WebRTC as far as I know,
while the rest are just show cases and demos of what can
be done with WebRTC for games.
Once I found Jocly, I had to have a chat with its CEO,
Michel Gutierrez. Heres what he had to say about Jocly, gaming and WebRTC.
What is Jocly all about?
Jocly is a board-gaming platform running in pure HTML5. The idea is to provide a
number of generic features that apply to a large number of games. This includes a
common artificial intelligence for playing against the computer, support for live and turnbased games between actual people, saving and loading games for analysis, a
developer API for modifying existing games or creating new ones, and many other cool
things.
One of the most remarkable features of Jocly is the use of the WebGL HTML5
technology. This allows viewing and moving around the board in 3D as if you had the
real game craft in front of you. This results in a much better immersion. Most popular
games and all the new ones we develop support the 3D view, but of course all games
are also available in 2D for browsers or devices that do not have WebGL capabilities.
The fact we use only standard Web technologies allows Jocly to run almost anywhere,
desktop, tablets and mobiles.
22
Tsahi Levent-Levi
What games do you support?

For now, Jocly is limited to 2-players games which potentially represent thousands of
games in the history of humanity. We support classics like Chess, Checkers, 9-men
morris, Connect 4, Reversi, , but also newly invented games like Yohoho, Margo or
Mana.
We currently have over 50 games but its growing quickly since developing a new game
is relatively painless as we capitalize on our existing libraries.
Why use WebRTC for gaming?

Jocly would exist even if the WebRTC technology wouldnt be available. As a matter of
fact, when we started Jocly, two years ago, having a live video chat between connected
users was just a dreamed feature. Its only 6 months ago that we realized the
technology was mature enough to be integrated into the service.
Playing board games is not just a matter of solving mathematical problems; it has an
important social dimension. Providing as many interaction channels as possible
contributes greatly to the player experience. Live text chat was obvious but audio/video
connection is definitely a step further.
23
Tsahi Levent-Levi
How do you make use of WebRTC inside Jocly?

The most obvious usage is to provide audio/video interaction between live players.
Since we make the 3D WebGL a key feature, we worked on integrating the WebRTC
video stream to the 3D scene. This way, you can see your opponent directly in the
game, which brings more value than just having a rectangular viewer in a corner of the
screen.
In one of our games, Mana, we use some image recognition algorithm to extract the
players face and stick it onto a 3D head mesh. This proves to be a lot of fun, but the
quality is not excellent and even if we have the feature in place, we did not use it on
other games.
We also use video streams inside 3D for displaying TV ads in dedicated sponsor game
apps, but thats not really part of the WebRTC specifications.
On what platforms does it work on?

It works in an interoperable way on the latest versions of Firefox and Chrome.

This is a new technology just being made available to the public. There is for sure many
good ideas about usage that have not been had yet and that is exciting! Moreover, like
for Web technologies, it does not take much investment to realize and test your idea.

Given that we already have the infrastructure to put the players in relation, there is no
need for a sophisticated signaling protocol. We just use our existing game signaling
channel in a proprietary way to setup the call and exchange face recognition data when
this feature is used.
24
Tsahi Levent-Levi
What technologies and architecture are you using there?

We are using a node.js server for all the players interactions and Drupal for serving the
files, however Drupal should be removed in the future and everything server side being
done through node.js. Websockets are used to exchange data in real-time between the
client and the server.
For the client application, we use heavily AngularJS to provide a very dynamic user
interface. We open-sourced a layer over AngularJS, Jaingee, that we use to maintain
the layout and provide the basic application behavior.
Regarding the gaming AI itself, both Alpha-beta and UCT are being used, along with
some in-house genetic algorithms to tune the game parameters.

There will be fewer opportunities for new ideas for sure!
Hopefully the WebRTC technology will be present on almost every device and since
Web based applications will be extensively used, we should have video chat and
screen-sharing features present in many places.
There also should be an open-source Javascript library that will have emerged to
provide trivial ways to integrate WebRTC into web apps.
Finally, I think WebGL/WebRTC coupling will be widely used as this provides original
ways to display video streams.
would it be?
If you have ideas, its now! Tomorrow will be too late to play in this arena unless you are
a big one.
If, as a developer, you hesitate putting the technology in place, give it a try, its certainly
much easier than you think.
25
Tsahi Levent-Levi

I cannot tell much about the protocol itself but there are big efforts to be done on the
interoperability and in browsers support like being able to switch easily between
cameras.
Whats next for Jocly?

Many more games, other game types like cards, better integration with social networks,
smoother mobile support, its the kind of project that can extend infinitely!
Now please excuse me I need to go play a game or two see if you can find me
online on Jocly.
26
Tsahi Levent-Levi
7. Jitsi: Emil Ivov

January 2014
Jitsi is an open source VoIP Client. But recently, it is also an SFU Selective
Forwarding Unit. This enables it to be used for supporting large scale video conferences
with multiple users. The Jitsi Videobridge became a very popular technology in many
deployments.
Whenever people ask me about VoIP client vendors you

know those writing software based IP phones, my instinct
and gut feeling says that they are more than challenged by
WebRTC.
This is why this chat I had with Emil Evov, CEO of Blue
Jimp, the company behind the Jitsi open source VoIP
client, was so interesting to me. Jitsi is interesting because they shifted gears towards
WebRTC and backend video bridge solution.
If you want to learn more about this transition Blue Jimp and Jitsi are making, then
check out Emils answers.
What is Jitsi Videobridge all about?

The IETF term is a Selective Forwarding Unit (SFU). More commonly, however, such
servers are known as video routers or MCUs. It is pretty much the same piece of tech
as the one Google use for Hangouts.
In other words, in a multi-party video conference, Jitsi Videobridge is the server that
receives video from every participant and then relays it to everyone else. Relaying the
video, as opposed to mixing it, makes for a very lightweight solution that could easily
have hundreds of participants on a single VM. It also allows for much better quality and
lower latency. This wasnt such a common approach until a few years ago when most
conferencing services used to mix content. As bandwidths rise however video relaying
is becoming the most reasonable choice.
27
Tsahi Levent-Levi
An interesting note here is that Jitsi Videobridge is not a service. It is an open source
(LGPL) server application that you can download and run in your own data center /
cloud / premises.
What about meet.jit.si then? Thats a service.

Right, meet.jit.si is a service that uses Jitsi Videobridge. It runs the JitMeet application.
Philipp Hancke from Estos, who is known to stop by this blog on occasion, wrote a JS
frontend for the bridge at the end of last year. It was then contributed to the community,
became JitMeet and we have been working on it together ever since. The power of
open source
Still, none of this is a closed down service. Everyone can download, deploy and run the
different components as they see fit.
How about Jitsi? What is it and how does it fit?

Jitsi is where we come from. Its an open source video communicator client with a lot of
features and a significant focus on security and privacy. It supports things like ZRTP
and OTR for call and chat encryption. This has made it rather popular after the Prism
affair last year.
For a number of years (more than ten actually) we have been evolving Jitsi in a number
of ways. We got to a point where our media stack was quite feature rich: we had ICE,
SRTP, audio mixing and video routing. So we thought that we should make the core
available for others to use.
This is how libjitsi was born. Its basically an alternative to the webrtc.org media stack
and Jitsi Videobridge uses it to provide its video routing features.
28
Tsahi Levent-Levi
So, you started from a VoIP software client, and now offer a MCU of sorts. Why?
Great question! Often, while working on the client, we were frustrated by the lack of
advanced video features in existing media servers. The thing is that Jitsi could already
host conferences even as a client but doing it on an end-users laptop is rarely a good
thing. You run into all of these bandwidth and reliability issues.
So, we thought, why dont we push all this to the network?
We did and this is how Jitsi Videobridge was born. We did our first release of the bridge
in January 2013. Then, we started adding WebRTC compatibility.
Luckily our friend Tim Panton and the Bouncy Castle team had already taken care of a
DTLS implementation for Java and we used that. We also added ICE support through
our ice4j lib. Then Philipp Hancke came along and started playing with all this and
eventually came up with what later became JitMeet.
Exciting times!
Being an open source vendor how do you make a living out of Jitsi?
We sell development. Weve been doing this for quite a while now. We
founded BlueJimp, the company I work for, in 2009 and we started this model with Jitsi.
It would always go the same way: wed come up with a tech and then people will come
by asking us to either extend it or adapt it to their infrastructure.
Right now it seems that the same is also working out pretty nicely for Jitsi Videobridge.
People have different ideas and different requirements for their services. Open source is
great in that it gives you a head start for free, but sometimes youd turn out to be
missing last 5% of functionality that you need. Thats where we come in with BlueJimp.
We are always considering other options of course, we like changing and evolving, so
far however, this model is working out just fine.
29
Tsahi Levent-Levi

I love the energy that it creates in the RTC diaspora. Weve been having a number of
technologies for years only never using them: ICE, Trickle ICE, Bundle, rtcp-mux,
TURN/TCP, SCTP, FEC, RTX Weve had all these techs for ages but they were only
sporadically employed here and there. In some cases, like Trickle ICE or Bundle, they
were actually strongly opposed at the IETF.
Now everything has changed. Everyone is implementing ICE, everyone is doing SRTP
and the IETF is fervently working on specifying the missing pieces. For some of the
techs, the people who were once opposing them are now pushing or even chairing the
efforts. Its quite interesting to watch!
Obviously end users are the big winners here as quality video communication is now
much more accessible than before and they are beginning to see the benefits in places
where such integration would have been unthinkable a few years ago.
A second thing that I love about WebRTC, this time more as a Jitsi developer, is how it
makes our lives easier in so many ways. It adds a very easy way for us to provide
applications compatible with Jitsi Videobridge. You now only need to go
to meet.jit.si and you can try it out. You can still end up installing Jitsi for a number of
reasons (privacy for one) but the entry-level barrier is much lower.

I know that this is a favorite topic of yours :). Having been wedded and divorced with
signalling protocols twice in the past we are now very pragmatic about these things.
Jitsi Videobridges arch is very protocol agnostic. It only cares about RTP and media.
This is very important because people are likely to want and integrate the bridge very
differently depending on their service requirements.
JitMeet on the other hand, the JS app that runs in the browser and that we currently use
to demo the bridge, uses XMPP and the COLIBRI protocol. Why? It makes our lives
easier. Heres an example:
After Philipp created the first version of the JS app, adding instant messaging was one
of the most obvious feature requests. Well, XMPP made this a matter of literally minutes
for him. In the future, things like sharing nicknames, showing participant rosters, adding
moderation, sharing slides, all of these are all be made very easy with XMPP. We are
glad we went that way.
30
Tsahi Levent-Levi
This doesnt mean that we consider XMPP the right choice for every situation. We dont
and I dont believe anyone does. Signalling protocols are just a tool. They are solving a
bunch of problems, so if you are on a path that would put you against such problems it
only makes sense not to reinvent the wheel. Also its not a decision that is taken once
and for all. You can always change if things dont work out. Still, it is much easier to
begin with a tool and then rebuild it your way based on experience, than it is to start
designing from scratch while you dont even know where you are headed.

Jitsi Videobridge is almost entirely home-grown. We do use the Opus reference
implementation, but everything else is libjitsi and ice4j. As for the rest, our meet.jit.si
deployment currently runs Prosody and Nginx.
The rest of the logic lives in the JS.

I see it actually taking off at that point. People really dont know about it yet. Ive been
quite surprised to find this even when talking to VoIP professionals. I guess thats
partially due to lack of support from some of the top 5 browser vendors and another part
to the stability issues that still float around.
We are clearly still in the early stages. Standard multi-stream support is still to come
and the differences between Firefox and Chrome are still substantial.
Obviously well get through all this because WebRTC is worth it but it wont happen fast
because theres a lot of complexity. My expectation is that by the end of 2014, early
2015 we should see the other two major browsers join the parade. Interop issues will
probably subsist through most of 2015. I suspect that by 2016 we should see a
significant surge in adoption and WebRTC will be on its way of becoming a mainstream
tech.
31
Tsahi Levent-Levi
would it be?
Well that would depend on who they are. I definitely wouldnt want a surgeon to
operate on me through a WebRTC app.
To all those who are thinking of adding non-critical RTC features to applications: this
should really be the first thing you look at.
Oh and of course: use trickle ICE!

I think wed be better off without SDP. I was among those who thought it a good idea
early on, but that was before we realized how unsuitable it was for all the variety that
WebRTC has to offer. We are no longer in a caller/callee model and Offer/Answer
doesnt fit that well.
Obviously we cant just dump it now. We are too far ahead, but I think what the ORTC
community (ORCA) are looking at, a lower level API that would allow the existing one to
be implemented on top of it, is a very interesting approach.
So I am looking forward to a better WebRTC 2.0
Whats next for Jitsi?

We have a bunch of interesting problems to solve with Jitsi Videobridge: optimizations
for conferences with hundreds of participants, improved mobile support, SVC and
simulcasting. Well be tackling these in the future.
As for Jitsi, we are about to start building a new HTML5 based graphical user interface
that would allow us to share a number of GUI elements between JitMeet and Jitsi. This
should allow us some very interesting combinations between rich and web RTC clients.
We are looking forward to making it happen!
32
Tsahi Levent-Levi
8. CallStats.io: Varun Singh

January 2014
I learned about CallStats.io when I worked intensively on application monitoring. The
idea of having a cloud based solution with very little integration points that can monitor a
WebRTC service had its appeal. CallStats.io are almost alone in this domain as we
see more WebRTC deployments released to production, so will the need for their
service.
So, youve developed your video calling service with

WebRTC, and now people are doing calls with it all day
long. There are thousands of them. Millions. Do you know
how well your service works for them? The next step in the
chapter of WebRTC is dealing seriously with aspects like
performance monitoring, and callstats.io is one of the
vendors trying to tackle this topic.
Ive ran into Varun Singh, Co Founder at callstats.io a
couple of times, and I think the story of his new company
is an interesting one very different than most video performance monitoring solutions
that are out there for non-WebRTC deployments already.
Heres what he had to say.
What is callstats.io all about?

callstats.io provides performance monitoring services for WebRTC systems. Speaking
with several WebRTC application developers, we found that 1) they have inadequate
tools to measure performance of the video calls served by their service, 2) not all of
them understand or have sufficient knowledge to understand video performance, and 3)
have the expectation that the underlying system should just work as they intend it to.
callstats.io as a first step provides APIs that are integrated into an WebRTC application
to help monitor the performance of the media flows. Our system is built bottom-up, we
observe each flow in a conference, aggregate the performance of all participants in a
conference, and lastly, the service level. As a second step, callstats.io provides
guidance to the application developer or WebRTC service provider to better manage the
33
Tsahi Levent-Levi
multimedia experience. We are working on a notification and a diagnostic system to

help with deployment and operational issues.
We are excited about callstats.io and are working with:
Application developers building WebRTC applications.
WebRTC SDK providers.
Infrastructure and service providers (MVNOs, ISPs, equipment manufacturers).

I have personally been working with congestion control for video telephony for the last 8
years and have waited a long time for video telephony to become a first class citizen of
the Internet. Our general belief is, WebRTC will commoditize multimedia communication
and instead of being the focus of the app, it will be a feature. One concrete example of
this is: imagine being able to talk to potential apartment renters or house owners on
Airbnb, you dont have to reveal anything more than your Airbnb identity. Airbnb is just
an example, any marketplace would benefit from such a communication as a service,
and they would expect the underlying technology to work without tinkering too much
with it.
We are contributing to standards where we can and are collaborating with people
across the industry to help WebRTC deliver on the promise of ubiquity, high quality and
performance.
You went for a hosted monitoring solution. How did the idea come up?
In the last 12 months, while building WebRTC applications, we realized that one of the
challenges apart from building complex features is to measure the performance of the
video calls (or lack of measuring it). At the time, there was no StatsAPI (or webrtcinternals://) and we built a system outside the browser to monitor the performance of the
media flow(s), today we offer this as a component to measure performance of media
flows at a middle-box (media gateway, TURN server or conference bridge).
Meanwhile, many WebRTC developers and service providers faced similar performance
issues and they contacted us. The issues were mainly at two levels: service-level and
endpoint/users-level. Diagnosing at the endpoint or user level can be done locally;
however, the service level needs to be done at a centralized point (in the cloud). By
34
Tsahi Levent-Levi
offering this service as a hosted solution, we take the pain of performance and
diagnosis away from the application developers so that they can focus on building the
product or complex call features. The callstats.io dashboard currently displays service
level engagement, network metrics and user experience, and the possibility to drill down
to diagnose issues with individual users.
Can you share a bit more about the architecture you use for getting the data from
WebRTC clients into your backend?
The communication between an endpoint and the backend is over HTTP/Web sockets.
We provide two components: a client library for WebRTC endpoints and a connection
monitor for middle-boxes. We currently provide callstats.js (a javascript client library)
that communicates with our backend, gathers metrics and exposes an API to send user
events (muting, hangup, etc.). The callstats.js will be accessible at the beginning of
2014.
The backend collects per flow statistics and puts them through an aggregation and
summarization process to produce conference-level statistics (useful for multiparty calls)
and service level statistics. Additionally, the developers can input their application
constraints and let callstats.io derive the best set of optional constraints for each user
based on past experience. In this way, we provide a mechanism for a consistent user
experience for each user.
The backend also produces a dashboard for each customer, from which they can gauge
the performance of their service at various levels. In early-2014, we will release our innetwork monitoring module (as a binary module); it will provide an additional
measurement point besides the endpoints and help with diagnosing potential
performance issues.

There are currently many minor operational issues that need to be ironed out in 2014 for
WebRTC to be ready for Internet scale deployments, for example, transports (DSCP
markings, congestion control, circuit breakers). In 2 to 5 years, I foresee that many of
these WebRTC apps will migrate from being video calling/conferencing apps to be
components or features of other web apps.
Data channels present an exciting opportunity and possibly even become a transport
protocol. At the moment we are observing a re-advent in peer-to-
35
Tsahi Levent-Levi
peer/overlays/BitTorrent-like apps, but envisage these types of applications to mature

quickly. There is also the Internet of things (IoT) over data channels
would it be?
Developers building yet another SDK or video calling application should look at their
competitors and think hard about what or where they can provide value. There are
enough MCUs, SDKs and various video-calling services already out there. Therefore,
developers should try and integrate WebRTC into the flow of their web application, i.e.,
the video call should not necessarily start and end by pressing a button, but the
participants in the call should be provided adequate context, prior and after the call to
make the user experience frictionless.
Whats next for callstats.io?

A lot of exciting things are planned, we hope to deliver the components in the colour
blue in early 2014, stay posted for the updates.
The first will be callstats.js, it will be released in the coming weeks, developers will be
able to integrate it into their WebRTC application and they will be able to access the
app- and media-level metrics from the dashboard. Complementing the JS will be the
API documentation to help with the integration. Weve had a busy fall and foresee a
hectic spring. Happy New Year!
36
Tsahi Levent-Levi
9. Peer5: Hadar Weiss

September 2013
An often overlooked capability of WebRTC is its data channel. Peer5 were one of the
pioneers in harnessing that into building a distributed CDN solution something I found
surprising.
Ever since the Data Channel in WebRTC got implemented

by browsers, I wanted an interview with someone using it.
That said, I was also on the lookout to interview web
people and not VoIP people who happen to use WebRTC.
To that end, theres no one better than Hadar Weiss, CTO
and Founder of Peer5. Someone who guest posted here
about the data channel already. To me, it was fascinating
to hear about WebRTC from a perspective of a web guy.
What is Peer5 all about?

Peer5 is all about bringing powerful peer-to-peer capabilities into the browser. We
deliver content more efficiently and give better experience for users.
When did you start using WebRTC?

We started early experimentation in late 2011. It was the wild west back then, and
WebRTC was far from being standardized. Chrome and Firefox havent even integrated
PeerConnection yet. We played with an implementation from Ericsson which
customized Epiphany browser and included a proprietary API for data transfer. I
remember it was quite bumpy at that time but we somehow managed to pull a POC that
proved to us what can be built on top of WebRTC.
37
Tsahi Levent-Levi

That it breaks everything we know about the web. The most fundamental rule in web
development to me is the client side can talk only with the server. WebRTC changes it
so you can connect browsers and make them communicate P2P. Removing this
Client/Server barrier is HUGE and is changing and will continue changing how we all
think about web development.
You decided to focus on the data channel and in the domain of content delivery.
Why is that?
WebRTC has become really popular due to its main API which enables video (or
audio) streaming via P2P. This API is very useful in scenarios where you want to build a
1-to-1 video conference app. But WebRTC has a fantastic core which can actually
transfer any kind of data very efficiently. To fully leverage this core, RTCDataChannel
API was added. It is a more generic API which lets us send raw data, encoded in our
preference. This API is perfect for content delivery and we use it to deliver files, images,
audio, video and also dynamic real time application data.

We use a proprietary signaling protocol. Its a simple protocol weve developed in-house
and is fairly easy to work with. Our requirements are quite different from most WebRTC
apps, so although we are against inventing the wheel in this case I think it makes
sense.
38
Tsahi Levent-Levi

We are 100% Javascript on the both client and server. We run on node.js and use
WebSockets extensively for all the C/S signaling. Our coordinator server makes the
decisions about how to connect between the peers. Once the coordinator decides to
match two peers, theres a standard handshake process which involves an ICE server,
another piece in our backend.

Im not sure about WebRTC, I think its too soon to tell, and the specs are still evolving,
certainly the implementations. I do know that I wish IPv4 would have been written with
128 bit addresses. NAT is a pain that isnt going away anytime soon if ever.
Whats next for Peer5?

Recently, we have published our file sharing application that uses Peer5 platform
Sharefest.me. We aim to make it better, faster and more intuitive. We have rolled out
registration to its bigger sibling Sharefest for websites which brings Sharefest
capabilities into any website that wish to empower its downloads. Our API is also about
to be upgraded into a clean, easy to use interface for web P2P. There is even more up
our sleeves and were taking it one step at a time towards the vision of making the web
decentralized, faster and better. This is just the beginning.
39
Tsahi Levent-Levi
10.
Lantern: Adam Fisk
December 2014
WebRTC offers privacy that is unparalleled. There are many aspects to that. What
Lantern has decided to do with WebRTC to enable people to connect to the internet in
their own terms, and why they selected WebRTC speaks volumes.
I love it when people find unexpected uses to WebRTC.

This one is just such a case. Id like to thank @aswath for
pointing this one out.
Lantern is about getting uncensorted internet access to
countries with oppressive governments. To do so, it used
P2P networking and an app that acts as a proxy for
internet traffic. The interesting thing about it is that it
adopted WebRTC technologies to do so and with good
reasons.
Adam Fisk, President and CEO of Lantern, took the time
to answer some my questions about this interesting
service.
What is Lantern all about?

The core concept behind Lantern is that crowdsourcing access to the open Internet is
one of the few promising paths forward for bypassing censors in consistently and
sustainably blocking resistant way. Lantern makes it easy for anyone in the uncensored
world to quickly and easily make their Internet connection available as a gateway to
blocked content.
For a downloadable app that just needs connectivity, why bother with WebRTC?
WebRTC offers a number of advantages. First, Lantern relies on peer-to-peer
connections to make ordinary users available from their home connections as
proxies/access points, and WebRTCs use of ICE to provide that connectivity across
heterogeneous networks is as good as any implementation out there. In fact, theres a
40
Tsahi Levent-Levi
distinct scarcity of good libraries devoted specifically to NAT and firewall traversal, and
the Lantern team has parceled out specifically that piece from the WebRTC code base
in a library called Natty, available at http://natty.io/.
Beyond simple connectivity, WebRTC also offers cover traffic. Because WebRTC is
integrated into the browser, ICE is now a common protocol seen on the Internet.
Lantern seeks to blend in with this traffic, forcing censors to block ICE if they want to
block Lantern. WebRTC provides what we call cover traffic for Lantern.
Why not go for a browser extension model instead of an app?

Censoring governments have incredible technical capacity at their disposal at every
level from hardware to software to human expertise. They have visibility into all traffic
coming into and out of the country. While JavaScript in the browser has made incredible
progress in recent years, Lantern uses a number of technologies written in different
languages, including Go, Python, Java, C++, etc. That language flexibility allows
Lantern to do more powerful things and to integrate more powerful technologies that it
would be able to with pure JavaScript, giving it more of a fighting chance in the face of
censors.
Your app. What other technologies do you wrap into it besides WebRTC?
Lantern also uses a pluggable transport architecture that currently includes FTEProxy
(https://fteproxy.org/)
and
domain
fronting
(described
in
more
detail
at https://trac.torproject.org/projects/tor/wiki/doc/meek).
FTEProxy
uses
regular
expressions to specify how traffic over the wire should look, allowing that traffic to
conform to whatever protocol we specify. That again allows Lantern to blend in with
existing protocols, theoretically forcing censors to block things they dont want to block
in order to block Lantern.
On the frontend we use AngularJS and D3.

We use a number of languages including Java, Go, Python, and C++. We are
increasingly moving as much as possible to Go.
41
Tsahi Levent-Levi
Why Go?
Were porting a lot to Go for a number of reasons:
1. Its got great concurrency primitives, and we do a lot of concurrency
2. Its got great build-in networking, and we do a lot of networking
3. Its super fast and easy to develop in
4. It has great cross-compilation and relatively small binaries
Were also moving away from Java because the download size is so large, which is
particularly problematic for users in Iran who dont have much bandwidth.
What challenges did you have in using WebRTC for GetLantern?

The biggest challenge was extracting the NAT and firewall traversal components from
WebRTC into Natty. The WebRTC code base is a monolithic beast and takes forever to
build. The NAT and firewall traversal components are relatively small and extremely
useful independently. While we havent announced Natty publicly at all, were already
starting to see interest from other developers and projects. We really think Natty will turn
into a broadly useful component thats a part of WebRTC but simply modularized into a
separate library that run as a separate process and can be called from any
programming language.

I think the main innovation will be from web developers using WebRTC for new and
exciting applications. The beautiful part about WebRTC is that it creates a new peer-topeer platform that is only limited by the creativity of developers.

I actually think some of the Microsoft teams criticisms of WebRTC were valid, and they
came from extremely experienced developers. WebRTC is far too monolithic and should
be a more discrete and reusable assembly of a number of smaller projects that are
independently useful. Natty is one example, but things like QUIC should also really be
independent projects that happen to be integrated into WebRTC.
42
Tsahi Levent-Levi
Whats next for GetLantern? (Its really just Lantern =)

Were continuing to port more and more code to Go, which will significantly reduce the
download size. The download size is crucial in places with low throughput, particularly
Iran. That will also enable Lantern to be ported to Android.
43
Tsahi Levent-Levi
Appendix A: Finding out More

Other than this report, the following services are available:
BlogGeek.Me Blog
My blog is the place where the bulk of my writing exists. It is available freely and can be
subscribed via both RSS and email. See https://bloggeek.me
WebRTCweekly Weekly Newsletter

The WebRTCweekly is a weekly newsletter. It lists articles from around the web about
WebRTC from the past week. This service is offered freely and is curated by me and
Chris Koehncke. See https://webrtcweekly.com/
BlogGeek.Me Monthly Newsletter

I am publishing a short monthly newsletter. It includes an answer to a question I was
asked during the month, statistics out of the research on WebRTC that I am doing, an
interesting project and a few other tidbits. See https://bloggeek.me/newsletters/
Reports
This is my second report about WebRTC. To find out about other paid reports I have
written, see https://bloggeek.me/reports/
Consulting
I provide consulting services to vendors, especially around VoIP, video conferencing
and WebRTC. See https://bloggeek.me/consulting/
44

BlogGeekMe WebRTC Interviews Vol 1 201504

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BlogGeekMe WebRTC Interviews Vol 1 201504

Uploaded by

Copyright:

Available Formats

10 Interviews

10 Inspiring WebRTC Interviews

Google: Serge Lachapelle .............................................................................................................................. 3

TokBox: Ian Small ......................................................................................................................................... 5

Talko: Matt Pope and Richard Speyer ......................................................................................................... 10

LiveNinja: Emilio Cueto ............................................................................................................................... 15

Togetheroo: Bart Yeary............................................................................................................................... 18

Jocly: Michel Gutierrez ............................................................................................................................... 22

Jitsi: Emil Ivov ............................................................................................................................................. 27

CallStats.io: Varun Singh ............................................................................................................................. 33

Peer5: Hadar Weiss..................................................................................................................................... 37

Lantern: Adam Fisk ..................................................................................................................................... 40

Appendix A: Finding out More ............................................................................................................................. 44

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

What stories will you find here?

How Google sees the uptake of WebRTC by developers

Delivering a video communication platform to any developer

Reinventing group conversations

Marketplaces and click-to-call wrapped in one company

Gaming? Social? Video calling? Adaptablox has it all in a very

Board gaming meets WebRTC, on a shoestring budget

From VoIP Client to server side SFU

Monitoring WebRTC deployments

Serverless CDN for distributed content delivery

Ending censorship, P2P-style

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

1. Google: Serge Lachapelle

Serge Lachapelle is the guy in charge of WebRTC at

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

2. TokBox: Ian Small

This one is a doozy. There have been several acquisitions

What is TokBox all about?

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

Where do you see Flash within your solution?

What do you use for signaling?

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

Given the opportunity, what would you change in WebRTC?

Whats next for TokBox?

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

3. Talko: Matt Pope and Richard Speyer

There have been several high profile

What is Talko all about?

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

One-tap team conferencing: Theres no need to waste time setting up

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

Cross-Platform: When we first started working with WebRTC, we had to

What excites you about working in WebRTC?

2015 BlogGeek.me All Rights Reserved

10 Inspiring WebRTC Interviews

What signaling have you decided to integrate on top of WebRTC?