 My name's Greg, I'm a developer evangelist for Twilio. And just out of curiosity, how many of you have heard of Twilio before and know of Twilio? That's awesome, so cool. How many of you have used Twilio before? That is also so cool, all right, awesome. So yeah, so I'm a developer evangelist for them, and like I said, I live here in Chicago. I'm so incredibly happy to be here. This is to be able to speak at RailsConf. I'm programmed for a good chunk of my life, but I just picked up Rails about three years ago. And I just started working for Twilio about two months ago. And it's just been absolutely incredible. And so to be able to speak at RailsConf in the city I love for this company, it's like, I don't know, it kind of feels like a big accomplishment for me. So if you were to come up to me afterwards and you were to say, hey Greg, you just spoke at RailsConf in the city that you love, what are you gonna do next? What do you think I would say? She's going to Disney World. Today I'm right, I'm going to Disney World. I'm going on Saturday. So I wish I could say I actually planned it that way. My wife and I just happened to plan a vacation to Disney World, and it happened to be that we're flying out the exact day after RailsConf, so that worked out, thanks. And I don't know, when I was growing up, I absolutely loved Disney World. It was an amazing place for me. It probably was actually the happiest place on earth for me. So much so that when I was in college, I took a semester off and I went and I picked up trash at the Magic Kingdom. And I got paid $5.85 an hour to literally clean up puke. And it was awesome. But when I was younger, Epcot was my favorite. I didn't have much use for castles and stuff, but Epcot stands for experimental prototype community of tomorrow. It is a vision of the future. Epcot was built to inspire us about what is possible with technology, the ways in which technology can change our life and come up with new ideas and new ways to communicate. And the big golf ball here is actually a ride. It's called Spaceship Earth, if you haven't been there before, and when you go inside of it, you get in one of these cars that looks like this and it's not a fast ride. It's not a particularly exciting ride. What it is is about a 20 minute tribute to the history of communication. And you go through and you see these different scenes. And so you see the monks who were copying manuscripts by hand and all these guys are animatronics, they're all robots, right? Except for he might not be moving, he might be snoring or something. And then you see the printing press during the Industrial Revolution. And then you see the advent of the telegraph, the first time that we had real-time communications over great distance. And then we see the advent of the telephone system, the first time that we had real-time voice communication over distance. And back when I was a kid in the mid-80s and the late 80s and stuff, this was the last scene in the history. It was the vision of the future. It was a boy in America talking on a video screen to a girl in Japan. That was the vision of the future from the mid-80s. The thing about MCOT is that it's this vision of the future and the thing about the future is that it comes. And so every 10 years or so, they shut down Spaceship Earth for a few weeks and they update it. And I just found this out, I didn't know this was the case, I haven't been there in like 10 years but I'm gonna see this next week. But they added a new scene depicting what Disney considers to be a, what has been an important contribution to human communication as the telephone and the telegraph. And that movement is represented by was sitting in this garage, tinkering on the first apple. Disney believes that the advent of the personal computer and the proliferation of software has had a big effect on human communication as has the telephone. And we at Tulio would agree with that. Our mission statement is to change communications forever. Or at least that's the short version of it. The longer version is to change communications forever by migrating this industry from its legacy and hardware to its future in software. That's kind of a mouthful, so let me help explain that a little bit better. And it's a little bit easier to explain that by talking about other industries because we're seeing this trend everywhere. You know, Mark Andresis said software is eating the world. And what we're seeing with all these industries that used to be dependent upon hardware are now becoming playground for people who can write software, people like you. So what if I said change hosting forever by migrating this industry from its legacy and hardware to its future in software? Who might ever be talking about that? Anyone? Paroku. Paroku, yeah. Amazon, AWS. You know, it used to be that if you wanted to host a website, you needed to know how to do this. And now when I want to host a new website or create a server, I click that blue button up there. I don't know anything about hardware. These guys are a digital ocean, they have a, I'm guessing y'all have probably heard of them. They're awesome. I just started using them a few months ago. They have booth downstairs. What about this change payments forever? Who might this be? I'll call it Stripe. Stripe, yep, yeah, exactly. Who else? Brain tree, asshole. Yeah, brain power, brain tree. Yeah, it used to be that if you wanted to process a bunch of credit card to get by one of these things. And five years later, that was gonna be the exact same device as the day it rolled off the line. And today, Square spent so little money on the actual hardware, they gave it away. You know, they're not hardware people, they're software people. They're software people who are changing the payments industry. What about this change transportation forever? Who's doing that? Uber. How would you like to be the guy who owns the company that makes these things right here? It was like five years ago that life looked pretty good. You know, that you didn't have to change things, you could sell pretty much the same product you've been selling for the last 10 years. And then these guys come along. Uber doesn't make any hardware. They're software people. And yet, they're software people who have totally disrupted this transportation industry. We have, as software people, I don't think that there is any other skill set that you can have that gives you more power to impact the world right now than the skill set that you all have in here today. And so that's what we're passionate about. We're passionate about changing communications forever by migrating this industry from its legacy and hardware to its future in software. How do we use software? How do we empower all of you here to change communications? And there's a technology that's new. It's just in the last three years that's come around. It was not invented by us, but we love it. And it's called WebRTC. And we believe that it's gonna change the way that the world communicates. Just who here has heard of WebRTC here? I mean, you can see y'all showed up in the room, so it wasn't like totally uninteresting for you. What do I put in the water bottle here? Okay, so what is WebRTC? So WebRTC enables real-time communication in the browser via open peer-to-peer protocols. That's more of a mouthful than the migrating this industry from its legacy and hardware. So let's break this down a little bit. So real-time communication in the browser. We've had real-time communication on the internet for a while, this is not necessarily a new thing. Skype came out about 10 years ago and it provided real-time voice communication over the internet. Now we have Google Hangouts, which happens in the browser, but it requires a plugin in order to install. We've had real-time communication in the browser before, but it's always required plugins, especially Flash. And then you have FaceTime, which is, again, it's a standalone app that's not happening in the browser. And I don't know, like, everyone here is a web developer, I'm guessing. I have never tried to screw around with media before. I don't know if any of you have, but it's pain in the ass. You have to first figure out how to get access to the camera, how to get access to the microphone, you have to be able to pull in that data, you have to be able to encode it some way, and you have to figure out how to transfer it which is a little bit more complicated making HTTP requests. Then once it gets there, you have to figure out how to decode it. There's all this information going back and forth. It's way more difficult than building crud apps and rails. WebRTC gives us all of that for free. And so WebRTC is this open-set of protocols. It's this tool set that lives in the browser and it allows you to have access to the video camera and to the microphone, and it will capture that information for you. And then it will wrap it up for you and allow you to ship it off. So that's amazing. It's absolutely incredible that the tools we have and it's happening in the browser. Which is, you know, we used to have, you know, in Skype, we're used to installing these third-party apps, right? Which means that the other person doesn't have Skype and doesn't want to install it, you can't communicate with them. And it also means that if you wanted to build something that took advantage of real-time communication before you had to know how to build a standalone app. So that wasn't necessarily something that was open to web developers out there. Now, if you know how to build apps for the browser, especially it gets you in a second, it's all JavaScript, you can build apps that use real-time communication. So WebRTC is JavaScript APIs. It's actually three APIs that are in JavaScript. One is called GetUserMedia, that's the one that actually captures the media for us. That's the one that will open up the camera, they'll open up the microphone, start recording that information. And you have this other one called RTC Pure Connection, which we'll talk about in a second, but it's the one that establishes the connection that lets you communicate and send that information off. And then we have RTC Data Channel, which is actually super interesting. Whenever we talk about WebRTC, the first thing that comes up is video communication or voice communication. But the people who are really into this stuff are actually most into this RTC Data Channel one, or it's kind of the biggest unknown, because the use cases for the media stuff is pretty obvious. Although I'm sure we're gonna think of things that we've never thought of before, but this Data Channel one opens up a lot of opportunities that not a whole lot of people have thought through yet. And I'll talk about that again in just a second. A lot of people talk about it here, I guess, because that's where the slide is. So the thing with the RTC Pure Connection is that we're not bouncing these messages through a server. The way in which this is gonna work is that we're gonna open up a direct connection between two browsers. And so these guys have thought of using that Data Channel, they got acquired, there was something called Pure CDN. So this idea that as visitors came to your website, they could download those assets and then open up direct connections to other visitors who came to your website and serve that, you know, the Data Channel allows us to start doing things, thinking about things like bit torn in the browser. Let me talk a little bit more about that, the Pure to Pure Connection. So it's open Pure to Pure protocols. So this is the standard web model, right? We have data going to a server and coming back. What WebRTC allows us to do is to establish a Pure to Pure, secure encrypted Pure to Pure connection between two browsers. So this means that, A, it's really fast because the data is not going through a server. You know, like if you, right now you can have a situation in which you have two people sitting in Japan and their messages are bouncing off a server in New York before they get to each other. WebRTC can help figure out that, hey, you're on the same network. You can just open up a connection right here and you can communicate. It's also secure. Your messages are not going through a third party and all WebRTC connections or transfers are encrypted. So it solves a lot of security issues that people are concerned about these days. And it's also interoperable. If you have Skype, you can't talk to somebody on FaceTime. You know, you can't talk to somebody on Google Hangouts versus FaceTime. WebRTC is open protocol. So this means that, A, you don't have to get people to install special software if they have a browser and they can use your app. And these protocols mean that you could set it up while using the same protocols for this so that your app can talk to another app, which is super cool. All right, so WebRTC is going to change the world. So easy, it's amazing. It's actually unfortunately a little bit more complicated. That's the pretty picture. So is WebRTCReadyYet.com? This is a site that's put up by the people at NDN. And if you want to learn more about WebRTC, they're kind of leaders in the space. They're consulting shop out in Seattle. They've done some great tools, I'll show you. Actually, the talkie.io, the video conferencing thing. I showed you a little bit earlier, that's by those guys. And you have two people, they go to the same URL and it pops up, starts a video chat amongst you. So they're keeping a scorecard here of who is, what browsers are WebRTC ready yet? And you don't know those big black lines going through anything that's owned by Microsoft and Apple. Because they pretty much don't do anything unless you twist their arm to do it. Which also unfortunately means that WebRTC is not currently enabled on iOS devices. On Google, on Chrome for Android, you can do WebRTC. So that means you could build an app, someone could visit on their Android phone and communicate video chat with somebody else who is on the desktop. You can't do that on iOS unfortunately yet. And one of the things that we really need are for more people, more developers to start building apps, because Apple and Microsoft have proven they're pretty much only gonna do something if you twist their arm and do it. Like we need WebRTC to reach a critical mass. We need that killer app that everybody's complaining about that their iOS device doesn't do it. And so the best way to get them to make WebRTC a more open standard, or just more widely adopted, is we need developers to start building show of it. But Chrome and Firefox are fully supported. So this means that you can build an app in Firefox, use WebRTC in Firefox and someone in Chrome can use it and hopefully we'll get to the point where pretty much every browser, I don't really have a lot of hope for IE, but you know. And WebRTC does not do signaling. So I'm a Rails guy, I don't really know a whole lot about network protocols and stuff and I don't really get it, like TZKI, I feel like I kind of know what it is, I don't know how it works, I don't know if, any of you are like that, but this diagram that I had up here earlier, my surprise you that actually painted a little bit of a well symbol picture of how things actually work, it's not actually quite like this. So if I want these two machines to actually talk to each other, then I need them to open up a signal between each other, there's a whole lot of information that they need to communicate back and forth before they actually can start talking. And to use that, to set up that connection, we'll use STP or session description protocol and STP is gonna answer questions like, are you there, you know, who are you? What is it you're sending me? Are you sending me a video, are you sending me audio? How is it encoded? What am I gonna do with it when it comes back? And then this question of, which is a pretty important question now, first off is where are you actually? Because the slightly more complicated view of how the world actually works is that your computer's actually sitting behind a router. It's not, because I'd like to directly the internet and we use NAT in order to give that computer that's on the local network a local IP address and then it's hiding behind a router that has the publicly available IP address. So there's a set of protocols in order to figure out where these computers are so that one computer can figure out, hey, where am I on the internet? It's called ICE Interactive Connectivity Establishment. One of them is called STUN, which is how do we traverse the NAT? So the idea here is that you have a server sitting out in the world somewhere and this one computer's trying to figure out, hey, where am I? So it pings the STUN server, the STUN server relays back that computer's IP address and then this computer can send that IP address to the other computer and now they've found each other they can set up direct connection. Sometimes that doesn't work so we have this thing called TURN, which is like, hey, that didn't work and so then we just end up balancing messages through the TURN. The TURN takes care of it for us. I don't have much interest in any of this stuff. Like, it's kind of a pain in the ass and WebRTC does not include it and that's actually a good thing. The reason for it is that there are all sorts, there are flamers about what signaling protocol is best which the whole network connectivity thing is this whole other minefield and for WebRTC to have bundled that in, they would have had to come down on a hard stance. Instead, what they're saying is depending on your app, you can implement this in whatever way you think is correct and so it doesn't build in that signaling force. WebRTC also doesn't really scale well between multiple people so you can't do multiple connections but it happens through what's called a mesh network so for each additional person who's out of the network, everybody else has to open up a connection to them. So you run into these problems where once you start adding four or five people, like the number of connections grows exponentially and everything slows down. So on that talkie.io, you can get three or four people on there for video chat but anything more than that, it really starts to slow down and doesn't really work that well. And WebRTC doesn't do telephones. No matter what apps we're building, it's super cool we can do this stuff in the browser. The fact is that for most business applications, most communication is happening over the telephony network and so at some point, you're probably, if you're building a business application, you're probably gonna need some sort of way to get in the telephones but let's say that you're not deterred by those downsides there and you wanna get started, how would you go about doing that? There is a library called Simple WebRTC. It is built by the people at And Yet and what he has done is this guy named Henrik who also gave this awesome talk at Cascadia.js last year, talking about this stuff. He says a great deal of communicating this but with Simple WebRTC, it's just a set of JavaScript tools that takes care of a lot of this stuff. So there is a simple signaling server that's built in Node that you can set up and take care of some of these problems. He also standardized, even though they're open protocols, the way in which you implement something in Firefox is a little bit different than the way that you would implement it in Chrome when you kinda have to, they're just not entirely standardized and his library serves as a wrapper for that to standardize those protocols or the JavaScript actions for you. And then of course, I have an order for Twilio so it might surprise you that we have a way that you can take advantage of some of this stuff. So we have what's called Twilio Client and Twilio Client is a way to enable communication in the browser and we leverage WebRTC for some of it. It's not a fully, I'd say it's not a WebRTC solution and that you can't just use Twilio and solve all your WebRTC problems for you but it is a WebRTC-enabled solution and that we're using WebRTC to solve a lot of problems that we were doing before and they've become much easier for us now that we've been doing WebRTC or at least they will be more so in the future and a lot of the things that you want to do with WebRTC you can actually do with Twilio Client and we will handle the signaling for you, we will handle the issues such as what happens if the person who comes to your website is using Internet Explorer, they're using Safari, what do you do then? And the answer is that you fall back to a Flash plugin and that's kind of a pain in the ass to write and so we take care of that stuff for you. So with that I want to show you just a quick demo of what it looks like and do a little bit of coding here and just show you what it looks like to build an app that uses Twilio Client that would enable browser-to-browser communication or enable browser-to-telephone communication. Let me do this because it's hard to type one handed. All right, can you still hear me? All right, so the first thing I want to do, I don't know if I need to speak into this for the app or what, for the recording, but I want to come to my Twilio dashboard here and I'm going to create a new app and I'll just call this my RailsConf phone and I need to provide a URL for where I want Twilio to get the instructions from for what to do once I actually try to make an outbound call and once I've actually created my application here then I'm provided with a unique identifier for that app. So I'm going to build this thing in Sinatra. Ever familiar with Sinatra? So okay, so Sinatra for those of you who aren't, Sinatra is just super strict down web framework. So it's like in Rails, if you could just define your routes on the fly and then just kind of like stick the controllers in there at the same time, it just lets you really build things really fast. So I'm going to build a Sinatra app. So I'll require Sinatra, I'm going to require the Twilio Ruby library, if I'm assuming everyone here is Ruby programmer since you're here at RailsConf, if you're not or if you're into other things, we also have libraries for Python, we have libraries for Node, we have if you're a .NET person, which oh my God, does anyone here do you on Net? Wow, that's awesome, I didn't imagine. That's so cool, like do you, does your company also do Rails as well or is that something you do? I don't do it very much. You don't, okay, cool. Well if you decide you want to build something, you can tool in .NET, we got you. So and then I'm going to require some credentials that I have because I do not feel like sharing my off token and what not. So I'm going to just set up, this is basically like think of it from a Rails perspective as my route, my index. And what I need to do is send a capability token, is what we call it, to Twilio to let it know that this client is able to interact with Twilio on behalf of my account. So I'll set up, it's called capability and I'll use the Twilio library, this is one of those words I misspilt all the time, capability and I'm just going to pass to that my authentication information. And then once I have my capability token, I need to tell it what are the capabilities that I'm actually offering to the client, what am I letting the client do? And in this case I'm going to let the client have outgoing connections and I'm going to paste in my application ID that I just got. And I'm going to allow it to have, allow the client to have incoming applications and I just need to give this client a name, just so Twilio knows how to uniquely identify this particular client. And once I've done that, then I can generate my token and then I can use ERB to pass that token into the HTML and some JavaScript that I wrote ahead of time. Actually I say I wrote it ahead of time, I didn't actually write it ahead of time. What I'm doing here is just following along with the quick start guide. So you can actually go through the same thing and you can have this, if you are interested in what I'm doing here afterwards, you can recreate this whole thing in probably 15 or 20 minutes going through the quick start guides on Twilio's docs. So I'll save this, I just wanted to show you what this looks like. All right, so this is all of the, well, not many of you know me, but if you didn't know me or my wife would tell you that I am not much of a designer, so I can tell you I definitely did not do this part. But yeah, so it's probably about 15 lines of HTML, about 15 lines of JavaScript is happening and you can see that from the docs when you go through this. So what's going to happen here is I'm going to punch in a phone number, I'm going to hit the call button and when I hit the call button, Twilio's going to send that phone number, it's going to send the capability token or my client's going to send that to Twilio. And then Twilio's going to check see if I have the permissions to actually interact with that application. And if I do, then Twilio is going to go looking for instructions to say, okay, what do you want me to do with this information? And that's what I set up over here is I set up the URL, I said this is where you go to find that information. And so I'm just going to write a set of instructions for Twilio that will tell it what I want to do once I try to place the call here. And the way it works is that Twilio makes an HTTP request to my server. And so then my server is going to send back a response and that response is going to be in XML. And so my response is going to tell Twilio to dial a number. Now I need two numbers to make a phone call. I need a from number and Twilio won't let you just put any number on your caller ID for obvious reasons. But so this has to be a number that either you bought through Twilio, you can buy phone numbers on Twilio for about a dollar. No, for actually exactly a dollar. Or you can register, say it like your own phone, you verify how you can do two factor off, listen to your code and you can say, hey, I actually verified that you do own that number and then you can send calls from that. So I'll do that. I'm going to use my mobile number as the from here. And then the two number, I have my form set up. So Twilio is going to, or my client's going to take that number that I punched in the form, he's going to send it to Twilio and then Twilio is going to send that number back to this endpoint here when it makes that HTTP request. So that number is going to come through in the programs. All right, so there we go. So that's my instructions. I have five lines of instructions to Twilio of how to actually make a call. So they sent me an HTTP request, I send them a response, it says, hey, dial from this number to this other number. All right, so we'll reload that with open soft phone. And I'm going to call, once my loading page is here, so there we go. I'm actually calling my wife's phone because she was kind of not doing the work for the purposes of this presentation. So watch what happens when I call here. I get a little, a little warning from Chrome up here, just a permission thing. Chrome is asking me, do you want to let this application use your microphone? This is a native Chrome dialogue. All right, so prior to WebRTC, this would be a flash app asking for this. So, can y'all hear me? Sorry. So this would be a flash app asking for this. Now, like I said earlier, if somebody were to come to this app that I built, on and on WebRTC enabled browser, Twilio would figure that out and then we would serve up the flash app. So you can just build it once here and we'll take care of all the interoperability. I think that's what you pronounce that word. But yes, I do want Twilio to, or I do want Chrome to use this. So, so there we go. Then we're done. Now I can speak from over here. Hopefully from over here. And then I guess I said, well, the microphone would separate the lagging issues and stuff. But yeah, that's how you do it. But yeah, that's how you do it. You can. You can. You can. You can. Can we give you some feedback? I was doing this earlier. Earlier. Destroying. Destroying. All right. All right, so it's how you go to make a browser, call a phone, and that's it. Like I said, that's super simple and thank you for the applause. I love when that goes well. Like I said, I've only been doing this for two months, the live coding's still a little bit scary for me, but it's pretty awesome that it's that easy to do. So that was super small app built in Sinatra. There's a whole lot of cool stuff you can do with Twilio. So besides just making that first call, so you can do things like transcribing the call. You can do things like dropping 40 people or 100 people into a conference call. You can do things like recording the call. You can build an entire call center using numbers that you bought for a dollar on Twilio. And this is an app called Zest Phone, which was built by a company out in California. They are a finance company that uses big data in order to make better loans, I guess. And they built this whole call center. They're dealing with tons of phone calls and they open source the entire thing. It's all in Rails. So if you wanna study a really cool code base in Rails about how you do some more advanced functionality on Twilio, doing things like placing people on hold or the supervisor might be listening in on mute, sort of stuff, you can do all that using this package. So go to that Zest Phone, it's super, super cool. And you can drop this functionality into just about any app that you'd be working on. So it's just add on functionality. So if you ever have an app, you need it to call people or you need it to receive calls. Or you need that, you wanna build a soft phone so that you can have two browsers communicate with each other. So let's say that you built a multiplayer game and you wanted everybody who was in there to talk to one another. You can do that using the Twilio client as well. So that's it. Like I said, we're super, super excited about this. We're super excited about YMRTC but more broadly speaking, we're so excited about the way in which software is now enabling people like us, like people who know absolutely nothing about telephony equipment. It used to be that if you wanted to build a call center, then you had to spend $100,000 minimum. The first thing you probably need to do is hire a lawyer and you need to negotiate contracts with major carriers so that you can use their equipment and their lines. And you'd be locked in for a long time. They need to spend $100,000 on equipment and fill up a closet full of that. And now, like you need a free Twilio account. It's pretty crazy. And for literally, instead of hundreds of thousands of dollars for dollars, you could build a call center. You can take this Twilio client and you could buy a $200 Chromebook and put a mic on it and give it to a person in a call center instead of having to buy all the expensive telephony equipment we've always needed before. So, yeah, we are so excited. It's only about the way in which software is allowing us to make a huge impact on the world by just making it easier to communicate. And we fundamentally believe that the more we communicate as a society, the better our society would get. So, I'd like to encourage you to go play around with whatever you see or whether it's with Twilio client. Go use the tools, use the skill set that you have to go change the world. Thank you very much.