 OK, ready? Right. So, as this part of the slide says, my name is Steve, and as this part says, I'm a bit of a geek. Today it's on WebRTC, low barrier to entry, low barrier to exit question mark, meaning, is it true what I told you last year that this stuff is actually really easy? Yeah, no, it's not. This is not to say that WebRTC has things missing. WebRTC set out to do a job, which is to provide an easy way to get communications working peer to peer in the browser. This is not to say WebRTC is missing stuff per se, but there are things that you as a developer have to do to actually make it work. So I'm going to go through stuff in the API that needs work, stuff that you need to do within the browser itself, and infrastructure things that you will need to build by or used open source technical stuff for. And I might bring Singling into this because Singling is generally hailed as the thing which is missing from WebRTC. It's not, but I will mention it. So API, what do you need to do to get around the API problems? Well, the first is conformity. Because let's face it, we have a standard. WebRTC is a standard. And obviously, everyone follows the standard, right? Yeah, no. So there's problems there. There's functionality problems. Because obviously, after implementing the standard, you actually implement the things the standard says in the, no, they don't implement the standard in the right way. So you've got to work around the implementation things. And no one's ever released software with bugs in it. So you don't have to work around the bugs in WebRTC implementation. Yeah, there are bugs. So you've got to work around them as well. But apart from that, it's easy. So let's start with conformity problem. This is the first line that starts pretty much every slide you'll ever see on WebRTC. Get user media. Or in this case, WebKit. Get user media. You can see the problem with that already. It starts with the word web and ends in the word kit. Not all browsers are WebKit, funnily enough. So you have to make sure that all the browsers have their own little get user media. Because when people are developing WebRTC and the browser first off, they're thinking, well, I'm not quite sure if this is going to be the real standard. So we'll call it WebKit and we'll use get user media when the standard's sort of got finished and it's all nicely sorted. So hardly anyone actually has get user media. Everyone has their own versions. So you start off by writing this. Oh boy. Yeah, even Microsoft has their own little version. I mean, and when Apple finally get around to doing their version of WebRTC, there'll be an or Apple get user media. So your first line of code starts with that. Starts, you mean, to go on as they say. And you have to do that for everything. Get user media, peer connections. I can candidate session descriptions on URL. You've got WebKit, peer connection, MS, peer connection. You've got a Moz, peer connection. So your first line before you've even started is about 50 lines, just getting around that. But that's okay. We know it now. We can do that and everything will be fine. It's just annoying way to start. Constraints. That's easy enough. You know, I would like a video, please. I would like it this big. I want it this many frames a second. Would you please give me that video? And they're called constraints. However, some browsers don't use the same set of arguments in the right way. So you have to patch them for the various browsers. Firefox 37, for example, had a little bit of a screw in the Senate, which meant you had to munge the parameters to get it working. But that's okay. We know about that. Now, we didn't at the time. When Firefox 37 came out and everything suddenly broke, no one knew why. You had to go back and look at it. And unfortunately, if you're dealing with a product which is in the wild and you have to support browsers that might include Firefox 37, you still have to cater for that version and you still have to go and munge your parameters. But that's okay. It only happened once. No one's ever going to break their code ever again in the entire future of development. So this is the only time you have to do it. Yeah, I doubt it. No, two slides are the same. Okay. So with all this template stuff that you have to do every single time, someone thought, let's do it once. And we created Adapter.js. I say, not just me, everyone in the community. So Adapter.js does all the junk that you've just seen. Handles the Mozget user media and the MSget user media and the WebKit get user media. However, Adapter.js is not the answer. It's the start of the answer. It's not that well maintained. You are very likely going to run into a bug or an issue before the maintainers of Adapter.js run into it. So you'll probably end up finding that problem and think, why is Adapter not working? It's like, well, it isn't. They just haven't caught up yet. Functionality-wise, everyone does things their own way and the is WebRTC, I'm probably sending the way, is WebRTC ready yet dot com gives you a rough breakdown of what browsers support what. So you can work around all the different problems in all the different browsers because you still have to do that. And for some unknown reason, some browsers and some implementations just like using completely different versions of code. It's a standard iterator for each is kind of standard JavaScript stuff, but this changes between browsers, between implementations. So you've got to handle that as well. And this is stuff which will exist in your user code. This is not something that Adapter.js can fix for you. You have to go, if result exists, else do this one. Oh boy, how much more code do we have to write around a standard? Well, it turns out there's more. There are bugs in some of the versions. So if you say to, if one browser says to another browser, I would like to send some video, please. If the other one doesn't say, I accept to receive your video, then it will break. There's no reason why it should break. It just will. So even if one machine you think is working fine as soon as you connect it to the second machine, but you don't have the right parameters, which you only find out by trial and error or by having bugs, then you just won't get that connection. Okay, there is so much stuff broken in this. It's surprising anything works at all. So the browser, how can you control the technology or can you control the technology or the browser versions? If you can control the browser version, that's a good thing. Previous company in mind, we did education solutions. We allowed kids in one country to talk to kids, teachers and another. And we said, if you want to use this product, you must be on Chrome version 45 or above. That wasn't because we thought Chrome 45 or above is really good. It's that we didn't have the time, patience, effort to test every other version of browser. So if you can limit that, do it. It will make your life so much easier. Do you need the mobile? Do you need... It is possible to build WebRTC on mobile. The web part of WebRTC doesn't restrict it to being a web-only platform. Most of the time it is, and it does work on mobile. But if you can get around not supporting mobile, you probably want to look at doing it. These are the first versions for what it's worth that WebRTC will support it. Again, WebRTC gives you that blurb. I'll move on, and yeah, who cares? So, the next part. So far, all we've gone through is where does WebRTC work? Which browser is working? How do you fix around problems in each browser? You have the problem. It's like, it's a communication protocol. Communication is between two or more. So what happens if you stick a Firefox with a Chrome? Yeah, that doesn't work either. Everyone has got their own ideas about what codec they should be using. Hey, we've developed a really cool codec. We want everyone to use it. I'm an old browser. I can only use this codec. Well, use this really cool new codec. No, we can't. And some of the time you find that the browser, the browsers will communicate and say, okay then, we'll use the boring codec if you must. But it doesn't solve the problem that there will be issues with the various codecs between the various browsers. Again, if you can restrict it to saying Chrome 45 and above, you will have a much easier life. And if you say, yeah, really support everything, it's fine. The STP format, which is the session description protocol, this is the little blurb of text which says, I am a WebRTC client. I would like to communicate in this way, please. And the other machine goes, fine, I accept that. Sometimes they use slightly different formats, just enough of a different format to make your life annoying. And as we saw on the previous slides, functionality differences. If one side says, yes, I support this particular method and the other side says, I don't, you still have to cater for both and you still have to do your own implementations to get around those issues. This is very much a heritage thing. On a load of old Android devices, WebRTC was disabled by default. This is nothing you as a developer can get around. This is a UX problem. You have to teach your users that they need to switch it on. Most users do not know or care what WebRTC is. So you can't say, just enable WebRTC because they haven't got a clue. The infrastructure, this is generally the bit we excuse WebRTC from. All the stuff that sits around WebRTC is your responsibility. So if I want to have a call with you, for example, I have to have something in my app that says, I am Steve. I have logged on. There has to be something on your side where you log on and the server somewhere says, yeah, I understand who you two users are. I understand which browser you're living in and I understand how to get a message between you. That's the signaling parts, which is often quoted as being the missing part of WebRTC. It's not missing. It's not there for a reason, which is if WebRTC provided the way that signaling has to be provided, then you are stuck to using the WebRTC signaling thing and you can't do anything else. You can't do any clever stuff. You can't customize it to your application. There is no turn service by default, so you have to supply your own. A turn server is a thing which just basically sends media between one machine and another. So a lot of the time we call WebRTC a peer-to-peer protocol. So it goes from that client to that client in the browser and it doesn't even talk to a server. The problem is sometimes these users are behind firewalls. Sometimes these users have really weird configurations and the only way of getting a media stream from that machine to that machine is to go through a turn server. You send the media up to the server, it turns it around and sends it back to the other client. You need to supply those. And because media is quite an expensive protocol in terms of bandwidth, you don't get those for free. So you've got to build and supply your own turn servers. There's co-turners on open source one. It's another thing to do. If you want any kind of recording or transcoding, you want to supply that yourself. Again, not big or clever. It's just another thing to do. And once you have to do it, you have to maintain it. If you want mobile, again, you're on your own. And similarly, there's no testing for any of this. The idea of test suites kind of went out with the arc. So does anyone test their code anymore? Is that an antiquated idea still? Oh, there's three of us. Great. So there's no test for WebRTC. So if I'm trying to have a call with someone else and it's not happening, I have no way of knowing where that call is breaking. Is it because my browser is currently unsupported, is new, is broken, is old, is broken? I can't tell as an application developer if it's the user's problem, if it's the browser's problem, if it's the connection from the browser to their local internet, it's from their local internet off to their ISP, if it's on the whole backbone of the internet, or it's the other side. There is no way in WebRTC to work out where or why that call is broken. You just have to guess. Obviously, business logic would never be included in a standard. That's not its job. But there's a lot of things that I won't say management because that would be very mean to those in suits. But the problem with management is as soon as you say, oh, yeah, WebRTC, it does this. And they've read some article once and they think, oh, it's easy. It just does it all for you. It doesn't do any business logic. So things like, oh, yeah, I'm going to make a call into this website and I want it to go to the first available client specialist or support girl or support whatever. You don't actually have any of that code in WebRTC. That's all your responsibility. If you want to put a, please wait, your call is important to us, honest, you can't do that. You have to write your own stuff to inject messages into the stream. If you want it to scale, you're on your own again. As you'd expect, you've got to work out a way of saying, right, I've got a thousand people all trying to connect to each other now. What service do they, that's up to you. And again, for the fault detection, as I said, if there's a breakage in your WebRTC connection between A and B, WebRTC does not help you determine where that fault lies. So I thought, let's have a go at this. How hard can it be to build a WebRTC application just for fun? So I did. I totaled on to my machine, I opened up Sublime and I started typing. 1,800 lines of JavaScript to actually initialize things, do the whole Moz WebKit or is this MS Web, get user media or 1,800 lines. That's not a lot, but that's still a chunk of work to actually develop and maintain and get working. 1,500 lines of PHP. That's not to say PHP is bad, and I could have done it in 20 lines of Ruby, but it's a case of saying... I'm so glad someone got that. It's not to say that PHP is bad, but in order to do user discovery to say, my name is Steve, your name is Jill, I'm trying to connect to you. You need to find us now, this is, I need to send you stuff. 1,500 lines to just do basic connection to know who you are, and that's quite a lot of extra code. And that doesn't include the ROM, I just used Red Bing because it was there and it seemed simple enough. That's still quite a lot of code. And then there were custom JavaScript bits. And these are things like, you've got three microphones in your system, which microphone would you like to use? Little drop list, all those sort of things need about 400 lines of code. And that's one call between two people. That's not a room facility where multiple people could join. That's not some facility where I'm going to make a call and the first available person can answer that. That's just one call between two people. And we're looking at what? 3,500 lines of code to be built and maintained. And those 3,500 lines only work if everyone does everything right. I did not write a single error check in any of those 3,500 lines because that would double the code size easily. That's a lot of stuff you need to do for something that apparently should just work, that is a standard, that is out of the box and available. There's effort required. So it's not to say that WebRTC is bad. It's not. It's great. There is no other way that a box standard developer is able to build a Skype in a browser in an afternoon. Most people do not know enough about Codex to make this work. Most people don't know enough about transport systems to send that data over the web. They don't know enough about streaming technologies, about frames and so on. So it lowers the barrier to entry so that ordinary people like me can actually do it. Unfortunately, it doesn't lower it low enough so that you can do it safely and without a slew of bugs the very first time you try. It's very easy to get it working, but that leaves you down that path where you think, ah, I did this entire Skype in an afternoon. How hard can it be to do the next bit? Well, it turns out that it is actually quite hard to finish it, and particularly if you're working with manager types who look at it and say, well, you did all that in an afternoon. Well, you can do all these other features by the end of the week then because it doesn't work like that as if anyone ever thought it did. So that's pretty much my time. I think I've got time for questions and I can also update my scorecard. There we go. 16 done. Great. Any questions? Phew. We've got the time, so... Do you have any suggestions on how to debug these problems that you and you said to the real encounter? The tools that might help? Yeah, well, there's not that many. The biggest help is GetStats. So as part of the peer connection, there's an API called GetStats. This basically just gives you an array of parameters. It sends things like over the last second I've had this amount of jitter. There has been this amount of lost packets. It tells you that stuff is happening. It doesn't tell you where because browser is so sandbox, it can't tell you where. You have to actually start saying, okay, I need the end user to install something on their machine that then actually has that low-level access to say, well, can I, you know, like a trace for it, for example, can I see this server? Can I see the one after that? That's something else you've got to install over the top. The JavaScript API, which is all you've got to go on, doesn't give you any more than the GetStats gives you. Which is a lot. It's a good thing. You know, I've noticed this user's got this amount of jitter repeatedly. So ask them. I see a lot of problems on your line. Are you trying to download something in the background? Are tolerance running? Is someone streaming YouTube or something? And you could suggest things. But as the JavaScript API, that is the best you're going to get. Unfortunately. And from user perspective, there are other tools that are built in in the browsers that you have this inspector whatsoever that are called now. Are there other external tools that you could eventually use? Topbox did a tool which you could install into Chrome as an extension. And that would do a couple of things to help. But they're more aimed at the developer side. The developer focused user rather than an end user. You know, your granny's not going to be able to handle it kind of thing. Yeah, it goes from developer point of view. Yeah, from developer then. It's Topbox do a tool which is a diagnostic thing. That has a little go at trying to work out what's going on and going wrong with the connection. You also have some services like, for instance, call stats, I think. Well, it will provide you with a small library which you can embed in your application which will send all sorts of events and data about the peer connection to their servers and then you have some analytics board where you can see stuff happening. So they piggyback a lot on get stats. But get stats, it's, as he said, inconsistent across browsers. So they normalize this so that we can give you more palatable data. For example, not affiliated. No, am I. I have met the guy and he's a nice guy, but not affiliated. Yes, one there, one there. Can you repeat the questions? Oh, yes. Are you familiar with any promising frameworks and common business logic problems that you mentioned? Not aware of any directly. There's one or two that keep popping up every now and again. Can't remember the names offhand. But yeah, just Googling open source RTC. The problem with it is that because it's businessy logic things, most people don't generalize it well enough. They start saying I'm going to build this fantastic framework and then it sort of grows with the specifics that each businessy stuff needs and it's no longer a usable framework, which is unfortunate. The thing is, I say it's effort. It's 1500 lines of stuff. It's doable. Of all the problems I think here, the business logic one is the one I'm least worried about. You said the API everybody's made their own version. Is there improvement in that at the time or we actually get instant function names rather than a version for every browser or is it just terrible forever? Yeah, so the question is are we actually moving towards a single set of API names and methods and that and the answer is we kind of are. I don't think I will be giving this talk in three years, for example, because I think by then everyone said, yeah, okay, we get it. This is what we need to do. Unfortunately by then there will be a new version of standard and everyone will be leaning towards that standard so we'll have a different problem in a future domain. But it's certainly getting better now because it's been, I mean, WebRTC started in 2011. So it's technically an old technology now and at that point it's kind of consolidated to the point where people are going, yes, we know it's a bit different but this is enough to get us moving forward so I think it's actually going quite well right now. Unfortunately, as we say, the standard keeps getting added too so all the newer stuff but the basic call-to-call is getting nicely consolidated. Oh, yes. Oh, that was all the time. Okay, I'll take it offline then if you like.