‘Dr. Alex’ Gouaillard, Founder of KITE


MP3 Download

Hi Alex. I’m here with Alex Gouaillard and I’m really excited actually to do this interview because Alex is a real expert in some of the things that make WebRTC work today, and we’re going to get into that. I don’t want to steal any thunder here, but I think probably the best way to start is with a little bit of background.

You and I met a number of years ago at some of the WebRTC conferences, in standards work, and have known each other for a number of years now, and in a number of different contexts. But I don’t know that necessarily, my visitors to my site are going to know your background. So, would you be willing to give us a little bit of your background as it relates to this space? I mean, you can talk about other stuff too, but I’m really curious how you got to this point, not so much the specific work we’re going to be talking about, but just in your life. How did you get to the WebRTC space?

Hi, Dan. Thank you for having me. Sure, I can go quickly over my background. I’m an Electrical Engineer by training and I was focusing on signal imaging, video processing. So I went all the way to a PhD that was in video compression, so I’m not very far away from home working in WebRTC.

What is fascinating about WebRTC is that it’s made of different skills that usually you find in people that don’t speak to each other, so you have people coming from the Codec part of the science, you have people coming from the Telecom, and then you have people coming from the Web, and usually these three communities are not speaking to each other. You will not find one course that gives you all the skillsets to actually master WebRTC. I come from the Codec side of the Force, and all the people that come from the Web and the Telecom are equally good, we just meet in the middle.

It’s very multi-disciplinary, yes.


But how did that lead you to WebRTC itself?

As always in a good story, there’s a little bit of serendipity in there. I used to be in academia and I loved the research, which means I loved to focus on challenges and questions that do not have an answer yet. And while in Europe there’s a strong separation between industry and research that is supposed to be only done in the university, in Asia or in the US that’s not the case, and I love to actually work on problems that do not have a solution but also problems that are real world problems.

That led me to actually do a lot of round trips in between academia, university positions, Caltech, Harvard, things like that, and startups. I was working for the government of Singapore as a public researcher on different topics. And at one point I decided that that was too far away from the real world problems, and I decided to go back into a startup, and at that time — it was 2011, 2012 — Google gave the first I/O presentation on WebRTC and a very, very young startup — two people, three people — called Temasys was looking for someone to assess WebRTC in comparison with VOIP. Is it smoke and mirrors, is it a real thing that they don’t have the capacity to assess, and so they asked me to take a look at that. Long story short, I ended up being employee number four or five in Temasys, CTO, and now I’m in a new startup, still working on WebRTC though.

That’s how my WebRTC adventure started. A little bit of serendipity, a little bit of good timing, the right skillset in the right place, a little bit of everything.

Cool. Let’s go ahead and jump to the big thing. You’ve made some big announcements recently about testing, and there’s something having to do with flying, or air, or something up in the sky …

Actually you’re referring to the KITE product.


KITE is a very, very exciting project. In between my last two startups, I was working as a chief architect at Citrix, and across those two startup positions and a chief architect position at Citrix, I kept working with the standards committee, and I was specifically reporting to the group on the state of the implementation with respect to the standard and the testing.

I saw both on the standard committees and on the industry, whether it’s a big company like Citrix or a small startup company, a lack of the correct tools for actually testing RTC in general. In the working room, that’s the first time for Web technology that you had the need for P2P connection. A lot of the tool-sets were made to test what browser vendors call interoperability, which by their definition means the capacity of the website to appear and behave the same way whether you run it in a given browser or another one.

If my website works and runs the same, and you get the same look and feel and behavior whether you open it in Chrome or in Firefox, they call it interoperability. For people coming from Telecom, or from the Internet, and not the Web, interoperability means you have two devices, or you have two things really, don’t have to be devices, it can be people, it can be-

Endpoints, whatever, sure.

Communicating with each other, and understanding each other, hence the interoperability. With WebRTC, the interoperability problem became one more of the Internet kind than of the Web kind. So seemingly I need to be able to make a WebRTC call between Chrome and Firefox. And there was no tool in the Web, no core system to be able to do that. And so testing the spec only to make sure that implementation fits the spec and to see how much of the spec is implemented, what the coverage was in each of the browsers, it was an interoperability problem.

In the last [W3C] Technical Plenary meeting, one year ago, to compute the coverage, I had to print the specification on paper and go through the test line by line, and actually check each of the lines in the specification to say, “More or less we’re testing that many lines out of the total document.” That was not appropriate.

That’s the right thing, but when I was working at Citrix for example, we did a lot of testing, but the most difficult part was the end-to-end testing. People from mobile part had their own testing stack, people on the Web part had their own testing stack, people from the media server had their own testing. When you put things together, what you really want to try is, using the GoToMeeting Free Web app, calling people with the normal GoToMeeting with the full native application, and everything that goes in between, all the servers and everything. That was difficult because people did not have the same tools. There was not one tool that allowed for any of those kinds of calls between two types of endpoints, two types of clients.

And the startup had the same problem. For instance, when we started writing the infamous Internet Explorer plugin, then we had to test that thing at the same level as the other browsers, and we realized that, well, that’s hard. Developing an Internet Explorer plugin is easy, maintaining it in synchronization with all the browsers really is difficult. So the value is in the testing and the maintenance, not in the developing phase.

All of that matured with a lot of feedback from a lot of people from the working group, of course all the browser vendors, but also Cisco, Ericsson, Citrix, all those, into a project that I presented last year. I presented a design of KITE at the W3C last year and Google was nice enough to say, “I think that’s the right thing to do, and we want to be part of that project, and we’re going to help you make it happen.”

So actually I did not make the announcement, Google did a few weeks back because that’s a Google led project.

I’m curious … You mentioned that the different spaces had their own testing frameworks, right? So the browser vendors had a way to test just their browser, test them individually for traditional Web functionality, and that in mobile there were frameworks for testing communications.

What was it that really made you decide that there wasn’t anything else you could start from? You looked at it and you said, “This is really, really unique, and I cannot begin with any of the communications frameworks that exist.” I come more from the communication side originally, and we’ve been testing IVR systems, for example, in automated fashion for quite a while. So, what was it that you saw is really fundamentally different that no one had grasped and tried to address yet?

Right. That idea about testing is not an idea really. It came from a pain. As the original book said, “There’s no better project than when you scratch your own itch.” Right? So we were really scratching our itch. That was really a thing we had, that was really a need that everybody in the working group and in the entire ecosystem for that matter had, and everybody was trying to do something about it, but nobody had cracked, really, the big problem.

And, so, I did a background check for two years on that. Internally at Citrix but I reached out, to Cisco, to whoever we could approach, asking what’s the limit of what you have today, and we made a complete state-of-the-art study. And, we actually published it one months ago with all the solutions we could find, with all the links and everything, so people that are interested in the background work, it’s there.

What we realized is that the problem was difficult to solve in a small scope and easier to solve as a generic scope, and most of the people were too focused on where they were. Let me give you an example, Google has adapter.js, or has the WebRTC sample, and those are their own test, and of course they touched WebRTC so they need to do something about it. Because they are using GitHub, and because it’s mostly JavaScript … Well they use the GitHub hook, they use Travis CL, which is a traditional and a totally normal technology stack to test things that are in GitHub-

Silo unit testing essentially?

Correct, and in that case, that was commit triggered. The frequency is important, and that was limited by the technology stack. So Travis CL, for example, doesn’t run on all the operating systems you want to test. You limit it to one hour even though that’s not the bottleneck, and you can only run one operating system at a time. And so that would mean some test, but it would mean the test needs to be constrained on one machine, one single machine. Alice and Bob, they need to communicate the two instances of your client, they need to do in the same operating system.

Let’s say you want to be really thorough and test everything, you’re going to want to test Safari against Edge. And there’s not a single operating system that has those two browsers. If you take the Travis CL approach for example, you cannot test that use case. Some other people are starting to say, “Okay, we can actually leverage browsers that are hosted in the cloud.” There are things like browser stack that allows you to connect to the Travis and provides some browser for you to try.

Well unfortunately, the provided browsers are from the past, so the use case they’re really trying to approach is a game. People that have an application want to make sure that their application also run on all their devices, or all their OSs and all their browsers.

But if you, for example are a plugin developer or extension developer for the case of screen sharing, you won’t be able to use that service to test. If you want to test against early version of the browser like the development version and Canary to make sure to catch the bug before they go on production, you cannot use these services. The difficulty is, everybody was often constrained about the use case and all the tools that existed were so focused on the given use case that you could not cover all the cases.

And then, it came to me … “Okay, so what do you really want to achieve here?” Here is what I want to achieve, what Google wants to achieve first, and then what people outside of the browser vendors want to achieve.

And the rest of the world that had the need too.

The question is, I want to test all the desktop browser first, and then as far as possible the mobile browser. I’m only interested in Web app, if you’re using a native app, that means that you should use a Web app.

The scope of the project with Google is limited to desktop browser and mobile browser for the time being, which is already quite interesting. And there are some tools that do that. You have one tool called TestRTC for example that does that pretty well, and I’ll come back to that later.

Now the ecosystem, if you take a company like Cisco, Ericsson, or Siemens with Unify, everybody that has a framework with TokBox, they will tell you, “Okay, Web browser, interesting.” But 50% of the people that connect to internet, they connect on mobile through native app. What happen if I got some of those hybrid HTML5 apps? I would love for example to support Electron, I would love to support Cordova, I would love to support this, this, and that.

At the beginning I was telling you about the trigger, whether you want to be commit based or very simple, a maximum 20 minutes not to kill the efficiency of your developer. Some people want to do it daily, so you do it during the night, you have four or six hours depending on how long your developer sleeps, and how much coffee he had. Some people do it the weekend, and some of them sometimes want to do a full run just before going on production, that will run in parallel on the frozen tree so the developer are not going to push.

For me that’s one exit. Some solutions were doing very well, the commit-based like GitHub and Travis CL, some solution were better for full run extensive. And then you had the client side, some people only wanted desktop browser, that’s kind-of easy, some people wanted desktop browser plus mobile browser, that’s a little bit more challenging, but we still can do it, and then some people wanted that plus native application, including IoT. For example working a lot with the automotive industry and most of the panel you have in the automotive industry are based on Qt framework.

How small can you go? I mean, IoT really could mean embedded devices.

Small. Raspberry Pi. We did a Raspberry Pi with WebRTC with H.264 acceleration, hardware acceleration on the Raspberry Pi 3.

KITE was a tool that allows you to actually support all of that without thinking too much about it. There’re other angles after … I want to be able to use BrowserStack for the very, very old Operating System and Swarm because I will never be able to have either a virtual machine or a physical machine for that. But in some case, let’s say I’m a hardware developer of a game acquisition card or WebCam or things like that, I need a physical machine because I’m going to plug my hardware in and show you that it works right into those, capturing the media stream, the audio or the video track.

The rest of use cases are where you need a bare metal hardware machine to test the hardware and the drivers-

You need a lab. A physical lab.

But really, you never have a case where you can get away with only the physical machine, or only the virtual machine, only an ephemeral virtual machine, or only offset. We need to support all of those cases and easily, so people can have … For example on my machine I have a beta version of Mac OS final with a beta version of Safari Tech Preview for Mac developers. I want to add that to my test run as an additional machine. That should be easy. Let’s say I’m modifying Chrome, I’m a developer, let’s say I’m an Electron developer, let’s say I’m developing a plugin, I want the things that I just developed on my machine be part of the test run and run against more stable stuff wherever they run.

We kept that also in mind when we did the original design of KITE. And so, by doing a design that was more generic, we were able to not only fit each of the separate use case and do as well as they do, but also to cover more than they could do.

So that would even allow me, within my organization, if I wanted to do my own customizations to a browser, that I would still actually be able to include it in this framework and do that testing?

Yes, yes. Not only that, but Chrome nowadays is embedded in different things than Chromium. It works with Electron, it works with Chrome Embedded Frame, CEF, it works with NW.js, it works with a lot of flavors of Chromium that are used today to do native apps like wrapped Web app into a native application.

The most interestingly speaking, we separate the parts. The problem is that people were over-constraining the problem because they were assuming too many things. So we say, “Okay, the test should not assume anything about which client it’s running on, or which browser it’s running on.” So, the engine should not assume anything about the browser configuration or browser version and so on. It just checks that it’s here, and it does the load balancing of the test that’s being provided.

It should not know anything about the test. So the test is provided as an input. KITE, which is interoperability testing in general, connects to a Selenium Grid that is also provided, checks the available configuration, and prepares all the test matrix, and then runs them concurrently. Not all the browser and all the clients can actually handle concurrency, so sometimes running four processes means running four different machines. Sometimes you can run four instances of Chrome on the same machine. Edge for example and Safari can only handle one browser at a time, so there’s a difference. So all of that intelligence, all that knowledge is put in KITE and deals with it for you.

It also doesn’t know anything about the result. The test is going to generate some result, the stack is also going to generate some result, especially error messages.If you have an error message when you connect to browser stack, it’s really different than if your test run and the test generated an error. And you want to be able to separate those because they give you different information. The real failure is the failed test. It runs the way you wanted and gives you the error you were expecting. If the test is not run, that’s a different type of error. So what we do is, KITE is also taking in as an input the URL of a REST API where they were to send the result as JSON. That allows you to do different use case again. People that address only running on the computer and just want to see that, we provide a very simple Web page and server set along with a Tomcat server for visualization of the result. But if you are a big company, usually you have your own continuous integration framework. And you might want to send the result of that into something else.

So, live?

That allows you to pipe KITE into a bigger continuous integration pipeline that can be whatever you want because KITE is not assuming anything about the test. The only one that really needs to know anything about the output is the test itself. So the dashboard, the next step in the pipeline, needs to know a little bit about the test.

It’s also live, I mean that’s the point, because you are actually sending the results as they come. You could have a process where you’re watching it run live as well, and that may matter to you for the kind of testing that you are doing.

Right. So you can think about any kind of use case, but basically we send a request and we suppose that on the other side there’s some kind of REST compatible server that is handling the results. We’re not only keeping them in KITE. You can install locally on your machine that Tomcat server with database, and it is at least going to store the result for you, but we also have an output to the shell, to the standard output.

I really don’t think you want to do that because it’s pretty verbose. We have one configuration file with all the configuration we can make work, that results in two thousand five hundred thirty plus tests being run. You don’t want to read that on standard output. But, you know, it is possible, and just for the fun of it, we provide that little plug.

You’ve talked a lot about what it can do, and I’m curious. When you think back to your original need that you were trying to meet, several different needs, essentially you turned that into the one need that everybody has, to test in all these different configurations. How do you think things have turned out so far in meeting that need?

I think we’re pretty happy with what we came for. The first goal was to show that handling that huge matrix of configuration with different operating system, different browser, could be handled automatically. So what we did, we took a very, very simple test because the test was not the focus, and we took a very, very simple system to test against, namely we took appRTC and one-to-one audio and video call, that was it, and we were just checking if the JavaScript ICE connection state was moving to connected, which as everybody that does testing of WebRTC knows is not even close to enough.

But the idea was to show that tests against a live appRTC on the Web can be run on an arbitrary complex list of configuration without a blink, without adding complexity to the test, and without adding complexity to the system being tested, because we want the engine to be able to test Spark, WebEx, Duo, Allo, everything else.

And that was pretty well validated, pretty fast. Within three months, that thing was validated. Now, what is interesting is the state of the maturity of WebRTC. I remember when we were first talking, having a first one-to-one example working, was a miracle. There was an opportunity for popping some champaigne. Today, having a one-to-one call is business as usual, even too easy.

Originally, I remember 20 – 25% failure just on connection, on ICE and shaky things like that.

And by the way, that was just a few years ago, even. We are not talking 2012, we are talking about, even two years ago, maybe even shorter than that.

Two, three years ago. I’m following CallStats.io because they have really good stats on that, and I think they have enough volume to be pertinent and to represent, and I don’t think there’s a better alternative out there anyways. The latest number they showed in Beijing one month ago was around a few percent. The problem of connection now is pretty well understood. The problem we might have right now is with quality of the media, is with multi-party and then there will be the upcoming single-cast and multi-cast, and things like that. And that requires a lot of testing because the complexity of the test is much higher than testing just a one-to-one connection.

Now that the engine is stable, really the next step is to start having much better tests, so testing much more, implementing regression testing. So getting GetStats and make sure that the tests run at the same speed as time goes, and supporting the latest API, not only to help the browser get it right. That’s why Google is involved, Google, Apple, Microsoft, everybody. But also for the people that want to test the application in more drastic configurations.

In terms of the original goal, the problem is that I might need two different operating systems with two different browsers, and two different browsers with Vision and some people use Windows 7 and whatever. For me that’s already solved, with what we have today, and now we’re going in more complex tests in more controlled environments. There are a lot of things that can only be tested if you fluctuate the available bandwidth.

There’s a very interesting European project today called ElasTests, which is an implementation of Kurento test framework that is actually working on things like that, they are doing a very good job, everybody interested I think should take a look. I think they’ll have interesting result, but the idea is, the ramping up of the bandwidth at the beginning of the call, the bandwidth adaptation when suddenly the network goes back, this is what eventually makes a difference in the perceived quality of a call.

Whether there’s jitter and if you only base your evaluation of the quality on the result of GetStats, which are network level statistics, it doesn’t correlate so well with the human perception of the quality. We speak about objective metric as the one that can be computed by a machine, and subjective metric, which is the score a human will give to the call at the end of your line.

I think there is still a lot of things that can be done on the objective metric, so try to fluctuate the network and see if you can do that in a deterministic manner, and see if things end up the way you want it. Everything is open in terms of subjective metrics. There have never been any research in terms of subjective metric for real time communication. Netflix did some research last year in 2016, but that was on broadcast, which is very different from the real time, like you record ahead of time, you compress ahead of time, you can call everything, there’s a lot of things you control. When you do real time communication you don’t control as much.

We are doing a little bit of research on the side as well, on artificial intelligence applied to these metrics to try to be able to have a test, have them and a software, that would score a given call as close to what a human could do in terms of subjective metrics. So if you were giving a score of 9.8, it would give a score between 9.7 and 9.9. But of course, it could do it at scale.

The thing we see with the binary test, is it connecting or not? No, it is connecting all of the time, but is it of good quality or not? What happen if want to go higher resolution, can I sustain it? What happens when the bandwidth goes down, does it handle it? How well does it handle it?

That’s where we’re going to spend a little bit of time. I know a lot of people are excited about VR and AR, we are, but at the end of the day I’m saying, “We’re just Codec people that love mathematics and signal-processing.” We are going to go on the other side of the force.

Well you just want to make sure that the call is working the way people expect it to, right? And that’s I think where you started, with the fact that people just had no idea whether it was going to work. Where working can mean the browser, it can mean the communications channel, et cetera. That’s an obvious extension.

In this process, obviously things are still going on as you said there’s a lot of work still to do, and a lot of exciting stuff to do. Were there any parts of this process that went better than you expected? You were surprised and thought, “Oh! That was actually easier than I thought it would be?”

I’m talking about the process of building out this whole infrastructure, framework, et cetera.

We were really concerned about the maturity of WebDriver and Selenium, especially outside the browser world. That was, I think with the insight, a fear of the dark. After we did our homework, we saw that it was actually not that difficult perhaps to extend beyond the realm of browsers. We were also very, very afraid of starting to test multi-party and load testing and things like that.

Of course the engine is removing a lot of the problem, which is scaling the Selenium Grid, but we were not too afraid about that, we were really afraid about multi-cast in WebRTC, Unified Plan, Plan B. That’s still in flux. If you make the right choice in the beginning to focus whole days long, and here I want to publicly say that the Jitsi team, Atlassian, they really investing a lot of time to be compatible with Firefox and Chrome, and they’ve stayed very, very close to the browser. It makes it easier to test the browser with their system, because their system is already very, very close, and they are doing an excellent job there.

We started testing multi-party with them, they had already made a shim available for Unified Plan, Plan B, they had already tested all these and so on, and eventually that ended up being much easier than we do, so kudos to the Jitsi team, they really did a good job there.

So that helped you a lot. Good.

But I’m still afraid about the upcoming object model API, and the simulcast, the real, full simulcast case in the spec. And I think I’m not the only one, I think the browser vendors are like that. I was speaking with Bernard Aboba from Microsoft, he was telling me, “You know what? The one to one normal case and everything whether it’s RTC or WebRTC, I really got it covered, I can handle it, I’m testing it okay, there’s no problem, I don’t expect any surprise there.”

The problem I had is really with the simulcast in WebRTC 1.0 because then you introduce an SFU, and most of the ticket I get from people that complain about it not working, they don’t say WebRTC is not working, they say it’s not working when I use Janus, it’s not working when I use Kurento, it’s not when I use Jitsi. It will get different kind of errors depending on which SFU you use. There seems to be, first, a lack of reference SFU implementation, we would have complete spec run, and I feel in that respect, this is not the same problem we’ve done, where the Coturn project is really good, really a reference, and there’s only one and that’s it. That also shows that we need to test much more, that’s the case because there’s still a lot of error out there that might not be visible yet by lack of proper testing.

That I’m a little bit afraid of. That means writing the test against all those platforms, running them, collecting, I expect to find a lot of surprises especially at the beginning. Thankfully, there was a lot of good open source SFU and most of the team are normally very knowledgeable and willing to help and participate in the standard as well, so I hope that now that the tool is available we are going to see a speed up in the maturity of the standards we all want to see finished, be able to use as soon as possible.

And you’re right about the lack of a reference implementation in that space there. Any time you talk about communication, you have to care about both sides, and so the discussions have all been on the browser side and not on that SFU side. But, thankfully, there are experts there working on it. I wanted to ask… There’re many people who need testing. If you are somebody who’s just getting started with WebRTC and you say, “Okay, I’m going to build my own app.” And you build your own app and you go, “Wait! This doesn’t work. Oh crud! I need to test this and see which browsers support this, which browsers support that, what is it that’s working, what is it that is not working”, so you know what’s you and what is someone else.

If they asked you how to test WebRTC, I’m sure the simplest answer you might give would be, “Well, call me, and let me do it.” But is there any advice you might have for someone who wants to start on their own?

How can I test WebRTC is a very broad question, so my first answer to the guy is defining exactly what, and you know, drawing is winning, we have a game back home, in that case drawing is really winning. Draw the different pieces of your architecture and say, “Where do you want to test and from what perspective?” If you keep the scope too large then you’re going to fail. The second thing I’m going to say is that a lot of people have been there, so do your homework. There’s a lot of fantastic blog posts about how to test different parts.

When you have identified which part, even before then, if you write testing WebRTC blog posts right on Google, I’m pretty sure you’re going to end up with some very good blogs. A lot of them in WebRTChacks.com for example, that we still use as a reference, so then I give to my new employees when they ask questions.

Sometimes they are really technical, but not always, and it’s always good to do your homework before you start, just if only to narrow the scope to what is really important to you.

The second thing I would say is, WebRTC can look very, very easy. You can do your first demo in one hour with one-to-one call, and it’s beautiful, and you make us proud. But outside of that one-to-one path, you are alone in the jungle, and again you’re not the first one that has been there, and you are not alone. So if you don’t want to bump into a beginner error because you don’t know better, you have some project right here to make your life easier. If only one, use Adapter.js. If you have a Web app, or Web app wrapped inside CEF/electron/ whatever, use Adapter.js. It’s going to cover the first mistakes you would do or the worries, and those are painful ones, the first ones are usually the ones that takes a long time to understand.

If you still have some problem after you use Adapter.js, that’s where you need to get the heavy tools out. What we propose with KITE, Google’s core is open source and free like beer by the way, is one tool. It’s like a carpenter, you don’t see a carpenter doing his job with only one tool. He has the tool for the border, he has the tool for the big burn, he has the saw. Different tools serve different purposes, so it’s good to identify and actually on WebRTC.org there’s a page that starts to do that. Different tools that are available for you to test and access different parts of WebRTC.

I see the bandwidth, is it my ports? Can I have a network diagnosis that the remote user can actually use. So the answer is yes. All of the above, already exists, have already been coded, they are always one or two free implementations you can start with. Before you reach the need for consultant or the need for specialized tool, there’s a lot of things you can do already.

So remember, read and look, understand because this is a complex matter. Again you have Telecom, you have Web, you have Codec, you have a lot of things coming in. It’s almost impossible that you know all of them. And even after many years working in it, we don’t know all of them, and that’s why we all work together because someone is better at testing the network. Wireshark is an acquired taste, that I still need to acquire. I have to be honest with you.

But Dan when I speak with my Telecom guy that can do Wireshark blindfolded with the right hand tied behind his back, when I speak to him about H.265 Codec and entropy and things like that, I could speak Chinese to him that would be the same.
Go along, find the right people, there’s a lot of meetups, there’s a lot of documents. Don’t start right away by saying how difficult can it be let me run a test.


What’s next? Is there anything that you are excited about or that you think needs addressing? You talked a little bit about the direction you are headed, but is there something more that you are thinking about for the future, or excited to think about, or something that keeps you up at night. It could be like, “Oh shoot! What about this?” You told us some of that, is there anything else that you’d like to mention.

I’m still stuck at the last boss of Zelda on my Switch™ that keeping me up at night from time to time. But as far as KITE and WebRTC’s concerned, we are really happy with where we are, we’re really happy where it’s going, we have a road map that makes a lot of sense, and we have a lot of backing from the ecosystem. We just need to execute and focus on the road map and we’re good. In terms of WebRTC, I’m really excited about seeing SVC Codec coming in, VP9 SVC again, I’m a Codec guy so that excites me more than other stuff.

I’m lucky enough to have a team that shares these interests, so I’m working with a guy called Sergio Mulilo who just wrote a blog post on VP9 SVC. I think there’s a big interest in double encryption, more than people realized for very specialized, but actually quite big segment of the market, and think about financial institution, feel about government lawyers, hospitals, and….

Could you just say a bit about that? Just briefly say a little bit about double encryption and what that is.

There’s a working group right now at IETF called PERC for Privacy Enhanced RTP Conferencing, and they’re trying to come up with a template for dealing with double encryption on top of RTP conferencing, which specifically encompasses WebRTC and C. That’s really the two biggest application right now, and it’s still in flux, it’s still being discussed, and that’s actually a mandatory thing for people working in the financial industry, and in some other sector of the economy, and lawyers, hospitals.

Hospitals have a different regulation than the banks obviously. So you hear a lot about HIPAA for example and WebRTC mentor is really good at doing that. But in terms of pure double encryption for banks and stuff, I think one of the few companies, with Cisco and a few others, that is focusing in house and existing implementation in place today. And we’re trying to move the standard along as we do the implementation. To play nice with our neighbors. That means, also having a modified version of every single browser, having a modified version of Qt, of Electron, of everything with double encryption implements, they needn’t be testing them again.

That’s why KITE is very helpful for us to develop new technology because we have the capacity to take extensive rewrite away.

Double encryption is something that is super-cool, the more your procedures made a decision that didn’t make everybody happy I would say, to accept DRM, for streaming content into the browser, and now that opened the question, let’s say people want to have their own crypto-module, people want to use I/O information, or they want to use hardware based encryption for more security. Should we allow the crypto-module in WebRTC to be pluggable, just like it was allowed for the normal streaming for example?
That opened a whole new world of application right there, where we don’t assume anything about the crypto of the application. I actually have a lot of people that came to me to receive that specific use, and I think they’re going to show up at the next meeting so far or inevitably. We’re pretty active there.

Other than that, the global goal of what we do here in Singapore, in my view is to make WebRTC easier to use on embedded. Make some tools, make some installers, because compiling WebRTC is still kind of black magic, I’ll sign on Google. And so we think that the market is mature, I mean between two and four years ago, a lot of people say, “I don’t know if need WebRTC.” Nowadays people are more like, “I don’t know if I will ever be able to embed WebRTC because it’s hard,” when you are not in the Web application and so on. And when they succeed it’s like, “Well, I need to start asking more.”

We’re trying to make everything easier through different angles, that actually complement each other.

Is there anything else you would like to tell us? I directed the discussion towards KITE, and you talked just now about all the other stuff that you are doing. Is there any last thing that you are thinking, “Oh my gosh, I wish he would have asked me about this, because I’d really like to mention this.” Or did we get everything?

I’m trying to react to the pain-point that I’ve seen for the past fails with different people, though of course is very biased because I didn’t meet everybody. I think if people had specific pain-points especially in the C++ code, or relating to Codec and things like that, they are always welcome to contact us.

If we are not able to answer, we usually connect them to the right person, because it’s a small ecosystem, we have a good relationship with every other consultant, or product vendor, or application development shop out there.

One of the other research, well, quote “research projects,” that we have for next year is to develop more Codec support for lead Web artists. Google has just changed the design of WebRTC to support injectable Codecs, external, so it’s easier. But to be able to be injected, there’s still a little bit of work to be done. And so for example, I was speaking with a Vietnamese Telecom operator, that’s saying, “I want to do audio on me, and I want to do G.729.” Which is an audio Codec that went into the public domain not a long time ago. That’s completely free to use, but Google already announced they will never support, they will never put in WebRTC.

And for them it makes a huge difference because they don’t have to transcode, so the media remove the gateway, remove delay, they remove everything because they cannot communicate directly, send the right project. Whatever you think about the quality of that product, it has big impact on the design of the backend.

It’s said that people want to use H.264 with some extended profile, and some people want all the stuff to look a bit more exotic. We have the capacity to make that happen, and we want to make it modules. We want to go to the point where people go to a Web page and they say, “I want a WebRTC installer for Windows 10, 64 bit, debug please.” And it’ll show you the option, “Do you want double encryption?” “Yes please.””Do you want H.265 Codec? Do you want this Codec, do you want … ” So you click, click, click, click and then it compiles it for you and send it as an installer to your email address.
I think we’re six months away to be able to do things like that.

Well, I look forward then to interviewing you again, and hopefully maybe if you have some follow up articles, there may be follow topics that you’d love to come and talk to us about.

I would love to do that.

Alright. Thank you very much, it’s been great talking with you, and look forward to speaking again.

Thank you.

Thank you, Dan.

Dr. Daniel Burnett has a history of almost 2 decades of experience with Web and Internet standards dealing with communications, having co-authored VoiceXML, MRCPv2, WebRTC, and many other standards. In creating AllThingsRTC, Dan aims to provide the innovators in the real-time communications space a forum for explaining the topics that really matter.