BlogGeekMe WebRTC Interviews Vol 1 201504

7/23/2019 BlogGeekMe WebRTC Interviews Vol 1 201504

1/45

10Inspiring WebRTCInterviews

Tsahi Levent-Levi

[email protected]


2/45

Tsahi Levent-Levi

1 2015 BlogGeek.me All Rights Reserved

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


3/45

Tsahi Levent-Levi



Introduction

I have been running interviews with entrepreneurs making use of WebRTC since 2012.

There are already over 60WebRTC interviewson BlogGeek.me and growing.

I decided to curate 10 inspiring interviews out of that collection and provide them as a

single ebooksomething 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

2 TokBox - Delivering a video communication platform to any developer

3 Talko - Reinventing group conversations

4 LiveNinja - Marketplaces and click-to-call wrapped in one company

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

interesting package

6 Jocly - Board gaming meets WebRTC, on a shoestring budget

7 Jitsi - From VoIP Client to server side SFU

8 CallStats.io - Monitoring WebRTC deployments

9 Peer5 - Serverless CDN for distributed content delivery

10 Lantern - Ending censorship, P2P-style
https://bloggeek.me/webrtc-interviews/https://bloggeek.me/webrtc-interviews/https://bloggeek.me/webrtc-interviews/https://bloggeek.me/webrtc-interviews/


4/45

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 Sergeenjoy!

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


5/45

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

Voxeoa great example of a medium companyexecuting 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 createan 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?

+webrtcon google+ is a good resource. Our discuss list on Google groupsas well and

the

IETF

WebRTC

mailing list.All linked fromwebrtc.orghomepage.
https://plus.google.com/113817074606039822053https://plus.google.com/113817074606039822053https://groups.google.com/forum/?fromgroups#!forum/discuss-webrtchttps://groups.google.com/forum/?fromgroups#!forum/discuss-webrtchttps://groups.google.com/forum/?fromgroups#!forum/discuss-webrtchttp://tools.ietf.org/wg/rtcweb/chartershttp://tools.ietf.org/wg/rtcweb/chartershttp://tools.ietf.org/wg/rtcweb/chartershttp://tools.ietf.org/wg/rtcweb/chartershttp://tools.ietf.org/wg/rtcweb/chartershttp://tools.ietf.org/wg/rtcweb/chartershttp://tools.ietf.org/wg/rtcweb/chartershttp://webrtc.org/http://webrtc.org/http://webrtc.org/http://webrtc.org/http://webrtc.org/http://webrtc.org/http://tools.ietf.org/wg/rtcweb/chartershttp://tools.ietf.org/wg/rtcweb/chartershttps://groups.google.com/forum/?fromgroups#!forum/discuss-webrtchttps://groups.google.com/forum/?fromgroups#!forum/discuss-webrtchttps://plus.google.com/113817074606039822053https://plus.google.com/113817074606039822053


6/45

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 isTokBoxall 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 post-

sales 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.
http://tokbox.com/http://tokbox.com/http://tokbox.com/http://tokbox.com/


7/45

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 knowwhat value does Telefnica see in WebRTC and a videoAPI 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 OpenTok-

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


8/45

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 thelast 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 canread more about Rumor on our blog postfrom about a year ago.

Why did we call our signaling infrastructure Rumor? Because, of

course, nothingtravels faster than a rumor

The Cloud Raptor SDK, which we just introduced at WebRTC Expo, integrates a serverapplication directly into the OpenTok cloud by connecting directly to the Rumor

messaging fabric (you can findmore information on Cloud Raptoron our blog).
http://www.tokbox.com/blog/tokbox-builds-it%E2%80%99s-own-internal-messaging-infrastructure/http://www.tokbox.com/blog/tokbox-builds-it%E2%80%99s-own-internal-messaging-infrastructure/http://www.tokbox.com/blog/tokbox-builds-it%E2%80%99s-own-internal-messaging-infrastructure/http://www.tokbox.com/blog/introducing-cloud-raptor-sdk-robust-apps-made-easy/http://www.tokbox.com/blog/introducing-cloud-raptor-sdk-robust-apps-made-easy/http://www.tokbox.com/blog/introducing-cloud-raptor-sdk-robust-apps-made-easy/http://www.tokbox.com/blog/introducing-cloud-raptor-sdk-robust-apps-made-easy/http://www.tokbox.com/blog/tokbox-builds-it%E2%80%99s-own-internal-messaging-infrastructure/


9/45

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 serviceat the browser level,

and in the cloudmost 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 designon 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 developeris 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 buildingcustom 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.
http://www.tokbox.com/blog/mantis-next-generation-cloud-technology-for-webrtc/http://www.tokbox.com/blog/mantis-next-generation-cloud-technology-for-webrtc/http://www.tokbox.com/blog/mantis-next-generation-cloud-technology-for-webrtc/


10/45

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 stillahead of usand 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.


11/45

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 isTalko, 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 isTalkoall about?

Talko is an app for mobile team communications. We designed Talko for todays new

style of workanytime, 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 10xless. 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:
http://www.talko.com/http://www.talko.com/http://www.talko.com/http://www.talko.com/http://www.talko.com/http://www.talko.com/http://www.talko.com/http://www.talko.com/


12/45

Tsahi Levent-Levi



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

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.


13/45

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

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

TheICEprotocol is crucial to successful establishment of aRTPmedia connection,

especially when on a mobile device where the client is often on a 4G/LTE connection

and sitting behind multipleNATdevices. It is also extremely helpful in managingnetworks coming and going, for example when a user walks out of their house and

needs to transition from WiFi to 4G/LTE.
https://webrtcglossary.com/ice/https://webrtcglossary.com/ice/https://webrtcglossary.com/ice/https://webrtcglossary.com/rtp/https://webrtcglossary.com/rtp/https://webrtcglossary.com/rtp/https://webrtcglossary.com/nat/https://webrtcglossary.com/nat/https://webrtcglossary.com/nat/https://webrtcglossary.com/nat/https://webrtcglossary.com/rtp/https://webrtcglossary.com/ice/


14/45

Tsahi Levent-Levi



TheOpus audio codecis 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 yearsat this stage, a majority of the pipeline is running custom code.

Where do you see WebRTC going in 2-5 years?

We expect WebRTCand the forthcomingORTCto 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.
https://webrtcglossary.com/opus/https://webrtcglossary.com/opus/https://webrtcglossary.com/opus/https://webrtcglossary.com/ortc/https://webrtcglossary.com/ortc/https://webrtcglossary.com/ortc/https://webrtcglossary.com/ortc/https://webrtcglossary.com/opus/


15/45

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 inour 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 streamchanges. 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 languagesweve heard the demand and are excited to bringTalko to many more parts of the world!
https://medium.com/talko-team-talk-share-do/can-you-hear-me-now-d43dbb7b83e8https://medium.com/talko-team-talk-share-do/can-you-hear-me-now-d43dbb7b83e8https://medium.com/talko-team-talk-share-do/can-you-hear-me-now-d43dbb7b83e8https://medium.com/talko-team-talk-share-do/can-you-hear-me-now-d43dbb7b83e8


16/45

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, theplot thickens. LiveNinja decided

down the road to migrate from a WebRTC PaaS vendor into building their own

communications infrastructure. Heres why.

LiveNinjais 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 Co-

Founder at LiveNinja about their new service Katana. I

wanted to share that conversation with you here.

What isLiveNinjaall about?

LiveNinja is about creating and sharing in unique experiences that add value to yourpersonal 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 real-

time, 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 calledKatana.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.
https://www.liveninja.com/https://www.liveninja.com/https://www.liveninja.com/https://www.liveninja.com/https://www.liveninja.com/http://katana.co/http://katana.co/http://katana.co/http://katana.co/https://www.liveninja.com/https://www.liveninja.com/


17/45

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


18/45

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 tobe 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!


19/45

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

Gamesintroduced 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 isAdaptabloxall 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.
http://resonantgames.com/http://resonantgames.com/http://resonantgames.com/http://resonantgames.com/http://adaptablox.com/http://adaptablox.com/http://adaptablox.com/http://adaptablox.com/http://adaptablox.com/http://adaptablox.com/http://adaptablox.com/http://resonantgames.com/http://resonantgames.com/


20/45

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 basedvirtual 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 ourproduct 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 theirpreferred 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.
http://resonantgames.com/http://resonantgames.com/http://resonantgames.com/https://faketown.com/https://faketown.com/https://faketown.com/https://faketown.com/http://resonantgames.com/


21/45

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. Webelieve 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 prov ide

the stability or features that we needed we might consider another solution but so far we

have been pleased with their service.


22/45

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.


23/45

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.

Joclyis 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 isJoclyall 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 turn-

based 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.
http://www.jocly.com/http://www.jocly.com/http://www.jocly.com/http://www.jocly.com/http://www.jocly.com/http://www.jocly.com/http://www.jocly.com/


24/45

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


25/45

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.


26/45

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.


27/45

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.


28/45

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

knowthose 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 ofBlue

Jimp, the company behind the Jitsi open source VoIP

client, was so interesting to me. Jitsi is interestingbecause 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 isJitsi Videobridgeall about?

The IETF term is aSelective 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 andlower 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.
http://bluejimp.com/http://bluejimp.com/http://bluejimp.com/http://bluejimp.com/https://jitsi.org/Projects/JitsiVideobridgehttps://jitsi.org/Projects/JitsiVideobridgehttps://jitsi.org/Projects/JitsiVideobridgehttp://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-01http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-01http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-01http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-01https://jitsi.org/Projects/JitsiVideobridgehttp://bluejimp.com/http://bluejimp.com/


29/45

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 aboutmeet.jit.sithen? Thats a service.

Right, meet.jit.si is a service that uses Jitsi Videobridge. It runs theJitMeetapplication.

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 thewebrtc.orgmedia stack

and Jitsi Videobridge uses it to provide its video routing features.
http://meet.jit.si/http://meet.jit.si/http://meet.jit.si/https://jitsi.org/jitmeethttps://jitsi.org/jitmeethttps://jitsi.org/jitmeethttp://webrtc.org/http://webrtc.org/http://webrtc.org/http://webrtc.org/https://jitsi.org/jitmeethttp://meet.jit.si/


30/45

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 alreadyhost 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 vendorhow do you make a living out of Jitsi?

We sell development. Weve been doing this for quite a while now. We

foundedBlueJimp,the company I work for, in 2009 and we started this model with Jitsi.

It would always go the same way: wed come up witha 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.
http://bluejimp.com/http://bluejimp.com/http://bluejimp.com/http://bluejimp.com/


31/45

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

tomeet.jit.siand 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.
http://meet.jit.si/http://meet.jit.si/http://meet.jit.si/http://meet.jit.si/


32/45

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


33/45

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 withoutSDP. 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 thatWebRTC 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!


34/45

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, andcallstats.iois 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 onevery different than most video performance monitoring solutions

that are out there for non-WebRTC deployments already.

Heres what he had to say.

What iscallstats.ioall 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
http://callstats.io/http://callstats.io/http://callstats.io/http://callstats.io/http://callstats.io/http://callstats.io/http://callstats.io/http://callstats.io/


35/45

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

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

internals://) 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 mediaflows 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


36/45

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

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 gaugethe performance of their service at various levels. In early-2014, we will release our in-

network 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 (DSCPmarkings, 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-


37/45

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

If you had one piece of advice for those thinking of adopting WebRTC, whatwould 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!


38/45

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 whoguest posted here

about the data channelalready. To me, it was fascinating

to hear about WebRTC from a perspective of a web guy.

What isPeer5all 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.
http://bloggeek.me/send-file-webrtc-data-api/http://bloggeek.me/send-file-webrtc-data-api/http://bloggeek.me/send-file-webrtc-data-api/http://bloggeek.me/send-file-webrtc-data-api/http://peer5.com/http://peer5.com/http://peer5.com/http://peer5.com/http://bloggeek.me/send-file-webrtc-data-api/http://bloggeek.me/send-file-webrtc-data-api/


39/45

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


40/45

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 thedecisions 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 outregistration 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.
https://www.sharefest.me/https://www.sharefest.me/https://www.sharefest.me/


41/45

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 @aswathfor

pointing this one out.

Lanternis about getting uncensorted internet access tocountries 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 isLanternall 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
https://twitter.com/aswathhttps://twitter.com/aswathhttps://twitter.com/aswathhttps://getlantern.org/https://getlantern.org/https://getlantern.org/https://getlantern.org/https://getlantern.org/https://getlantern.org/https://getlantern.org/https://getlantern.org/https://twitter.com/aswath


42/45

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 athttp://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 incredibleprogress 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

athttps://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.
http://natty.io/http://natty.io/http://natty.io/https://fteproxy.org/https://fteproxy.org/https://fteproxy.org/https://trac.torproject.org/projects/tor/wiki/doc/meekhttps://trac.torproject.org/projects/tor/wiki/doc/meekhttps://trac.torproject.org/projects/tor/wiki/doc/meekhttps://trac.torproject.org/projects/tor/wiki/doc/meekhttps://fteproxy.org/http://natty.io/


43/45

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

peer 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

independe

Date post:	13-Feb-2018
Category:	Documents
Upload:	ashish-k
View:	212 times
Download:	0 times

BlogGeekMe WebRTC Interviews Vol 1 201504

Documents