 So, clearly you're in the session now hearing this, putting voice, video, and text into the rail. A quick introduction, my name is Tim Plank. I'm actually very proud of you on the State of Atlanta. Welcome. Hope you all have enjoyed Atlanta so far. You may also know me through some of my open source contributions. Just a quick show. Okay, has anyone heard of the Georgian? Has anyone used it? Come on. All right. Cool. I'm going to talk about a Georgian that you want to just quickly mention because it bears relevance to the talk. A Georgian is an open source framework for voice applications. So you can think of it as the rails of Super 11. A Georgian is for voice and for built-up video games. I'm also the founder of a company called Learn the Language based here in Atlanta. And this is what we do. We work with voice applications. We build them. We scale them. We do usability. This is a topic close to my heart by communications applications in particular. Today, I want to tell you why the web is a lot like outer space. Because on the web, no one can hear your screen. So let me just paint a scenario. Sometimes you're working with your app and all of a sudden something happens and you realize you need to speak with one of your customers. Now, what most of you are going to do is you're going to pick up a telephone. And the main problem with this is that when you pick up that phone, any communication that you have is now outside of your business process. It's not noted within the business application. It's not reported. The fact that you've been called and have it is in no way, in most cases, is in no way reflected in the state that you're going to your customer. And also the communication itself is fairly limited. You've got this really kind of crappy narrowband audio signal to talk through. You can't easily share pictures. You can't easily share links. You really don't have a very rich communication experience. Wouldn't it be cool if we could instead of having that phone call happen outside of the app, put the communication right into the application itself? That would be cool. Yeah. Okay. So that brings us to something called WebRTC. So, show of hands. Anyone heard of WebRTC? Cool. That number goes up every time I ask because it's absolutely an happy thing for me to see. Has anyone actually tried it? A couple. Okay. Well, hopefully at the end of this talk you'll have some resources for you that will inspire you to give you some information on how you can try it. For those who are familiar, WebRTC is fundamentally about audio, the speaker, the microphone, and the camera in the product, and they can use that in a web application. So what is it? It is the camera and microphone, but it's without any plugins. This means that if you want to go build a real-time communication app, it's going to take advantage of the mic and the speaker, of course, and kind of out. You don't actually need a flash. You need a drama. And all of the bad things that come with having plugins, such as crashes and ICQ, it's built right into the product. WebRTC additionally has functionality built into established peer-to-peer connectivity between two or more partners. This is really an interesting point, which I'll touch on in more than a minute, but connectivity across the internet can be really tricky with that firewalls and things like this. So WebRTC has functionality built into help traverse connections and firewalls. The last thing it provides is a common set of codecs for actually exchanging high-definition media. So I'll talk more about that in a second as well. So fundamentally, WebRTC is a JavaScript browser API. You tend to access it using JavaScript problems built in the browser. It can also be used for mobile, although in the mobile world, you get all of the backers to get the standardization, but that isn't universal, but you don't necessarily have the same API. It's different. I'm not going to talk too much about mobile today, but the standards for availability are really interesting. So these codecs, Ovis, G711, HD64, and VPA, these are what make very high-quality audio and video possible on the internet. G711 aside, which we really care about, Ovis is really a pretty amazing product. It comes from a lot of research, including significant contributions to Skype. And most of you have made Skype calls and you know this is just talking good about audio sounds. Ovis builds on that research. It actually goes further. Ovis, as a codec, is good enough, not only to transmit voice efficiently, which is to say, using minimum amount of bandwidth to preserve the size of the audio voice. It actually can scale up and also transmit music. So it's a very, very high-quality codec. It's built in the browser with no royalties. I mean, if there weren't, Ovis is entirely royalty-free. 264 and VPA are two competing standards for transmitting video. 264 is an amount of wireless. It actually is patent-encumbered, although Cisco has paid for licenses so that open-source software like Firebox. And eventually Chrome will support 264. VPA is actually a codec that Google acquired a company and then released all of its IP. So it's a fully open standard, open-license codec for video. And that's very exciting because that means that we'll be able to do video without being royalty eventually. It's still being brought out to it. But what these do provide you, built in the browser, is very, very high-quality audio and video. There are a few more alphabet soup type things that are built in the standard. SDP is the mechanism by which the two endpoints exchange information about where they are. I'll talk about it in a second. I study, in turn, these are the proper calls used to reverse the firewall. And then DTLS-SRTP is exciting because it is basically on by default in person. So all of your calls will be on the media and we're calling the average. So finally, what is WebRTC? A lot of people in the telecom industry get really excited about the idea of putting a telephone in a web browser. And please, if you take one thing away from today, do not take that away. It isn't to put a telephone in a web browser because we can do so much more. Web is a rich power of user interface possibilities. So think of it instead as communications in a web browser. And a quick note on the relevancy of WebRTC. This is a chart compared by this newly-funded chart I've got this whole time. Dean Mowley put together this chart projecting the top keyword of WebRTC. And the gray line of the bottom represents browsers. And we're pretty much attending that point today where about a billion, over a billion browser-based desktop browser-based devices that support WebRTC. The interesting part is the growth in tablets and smartphones because these communications options won't just be in the browser. They will also be on mobile devices, whether that's mobile-led or native to apps. Eventually, coming very soon, there will be a lot of WebRTC so further into WebRTC, you want to just give a real quick background on communication to phones. So this is how communications are facilitated today. The most if you pick up a phone, you might have your service to AT&T. When Alice wants to call Bob, she'll pick up the phone, she'll dial. That signal will hit AT&T. AT&T shoots over Verizon. Verizon sends it back down to Bob. This is called the travel sign. Pretty classic. There's a driver-having relationship and then all of those carriers being federated with each other. The advantage of this is that everybody can call everybody. We have one set of phone numbers and generally as long as all of the carriers federate, everyone's reachable. But there are a lot of problems with that because of the overhead that comes with all of that federation. There's a lot of innovation that gets lost. You just don't move very quickly when you have to use coordinate companies and then not to mention devices. Also, it's not particularly user-friendly. If you think about identity in the form of a cell phone, your identity is your phone number. The least is 10 random digits that are assigned to you by your phone company. There really be nothing to you and yet we come to be associated with this item. So this architecture has some significant drawbacks. The next kind of architecture is more of a triangle. That's a good example of this. You have one central service and you have endpoints that connect to it. These guys are able to innovate a lot faster because they control both the network and the endpoints. So we've got things like video, high definition calls. We have plenty of usernames that we actually picked in the process of signing up. But there are still two things that are problematic with this. One is that it's essentially a wall guard. I can't build them out that integrates with Skype all that well. I certainly can't base that in one of these processes. Which means, second of all, it's not great protection. I still have to go with separate service, separate applications to actually handle my communication. It's not big to my users' problems. So with my RTC we actually get to do something that looks more like this. We're still assuming it to keep the standard for the trial of the company. It's actually a more permanent track where the signaling goes back to the website. So again, I don't have to download any plugins. I just go to the web application and it serves me all of the tools I need to enable the team to use the right side. Second, the signaling and the media are separate. So what happens is when that call wants to be set up, Alice will send a request which just contains her information to the web server. That's off. But let's imagine you have a firewall here. The media actually is exchanged behind the firewall. So this has some really interesting implications to our performance. This has some really interesting implications for quality. If you are on a low bandwidth link, maybe you're in a... I was actually working in Barbados once in the internet connection off the island of death. So you have connections on the island but not on the island. You actually can still communicate with this exchangeable so that we're not using expensive bandwidth routers across congestive links. All of the video is being passed on the land. Even though the session is set up, it deals with it. So let's take a little bit further into how the WebRTC session set up might look. So we'll start with Alice using Firefox. She is going to send a request to initiate communication with pop. The request contains something called SDP, a session-districted protocol. For practical purposes, just think of it as a paid blob of text. But this blob of text contains a bunch of things which include her contact information in the form of an IP address and a port. It contains a list of the codecs that her device supports. This being WebRTC, I don't know if this will be introduced to court. And it contains as well a public key that can be used to encrypt communication and send to her. Now the Web server doesn't have to do anything with that blob. Again, it's just okay. All it really has to do is forward that on to the recipient, in this case pop. So pop, upon receiving that offer, generates his own response. Contains largely the same information and passes it back via the Web service to Alice. Now at this point, a whole bunch of packets start flying between Alice and pop. And then turn. So what those three things do are, I see in particular enumerates all of the network interfaces that you have. So you might have a LAN, you might have a TPN. You also ping out to the internet and figure out what your public IPs are. And I'll use all that information to try to tell Bob how Alice can best be reached. They can make a direct communication on the LAN grid. If they can, because there are several firewalls, maybe we'll do something, Peter's doing a firewall, that's where the stun comes in. In worst-case scenario, if they can't make direct communication either locally or using stun to reverse the firewall, then there are relay servers called turn servers that will actually proxy the media. They'll actually just receive from one party and pass it back together. Now because they exchanged private keys using the signaling layer, what will actually happen is the media will be printed. So even though the turn server technically is in the pouch medium in the worst-case scenario, all that audio is still in the Persian. The turn server can't see it, can't do anything about it. It's just data being passed back and forth. So this baked-in security is one of the big things with WebRTC that is, I think, relevant given our friends in the NSA who would like to jump into all of our conversations. Properly deployed WebRTC will stop working able to see into that communication. Now one of the points I want to make about signaling is I've used WebServers as my example but it really doesn't have to be WebServers. All you have to do is get that SDP and then play as it's going to be. We've done deployments with XMPP as a carrier for this domestic. We can do it with Redis. I've even seen an example where someone actually took it, put it up on a text file on a USB drive and carry it to the computer and load it back in. Which would be the least efficient way I could possibly make because I could call, but it doesn't work. Alright, so that's enough about the deployment. What really gets me excited about the applications is how we'll use it. So I've in the last couple years of building these applications I've thought about what it takes to build these apps and what attributes applications like this should have. So I came up with this and I want to share that you should consider them designing communications applications. So a modern voice application should be adaptive, which to me means that it should take advantage of the capabilities of these devices on which it's running. It should be fluid, which is to say it should be able to move across devices and across time and even across users and still preserve the context of the conversation. It should be contextual because really this is the value of what we're building. The communication happening in context with whatever application it supports. It should be trustworthy because the worst thing in the world is to communicate something sensitive and have it revealed or realize that the user is impressed. And the last point is that it should be reference. So we go a little bit more into each of these. Adaptable. What does it mean to be adaptive? So if Alex again is on Firebox, she has a pretty broad range of options available. She has a keyboard for input. She obviously can set text back and forth. She's got a right amount of camera and speakers. She can really have a very rich communications interface. And maybe she's talking to this guy over here who's on his iPad with a very similar set of input options available. So whatever app we build for them might enable video conversation, audio conversation, text, link sharing, all that. Now this one wants to join the conversation as well. She's on a smartphone and this particular smartphone either doesn't have a camera or maybe she doesn't have enough bandwidth or maybe not a battery to support a video screen. So she still wants to participate in the conversation. She still wants to talk about whatever the issues are. Well, she can still both receive text messages if we have a send or receive text messages if we have a mobile app to play. And she can also participate by audio. So think of this sort of as your conference call where some of the people have a side channel where they can use video with richer communications whereas this third party really is only in by voice. But critically, she is able to participate. The same is true with this poor guy. I don't even know what he's talking about. But he can still join it, right? He can still talk. And then we have this last guy who also has a browser but either his microphone is broken or maybe his baby is asleep and he doesn't want to talk. I mean, actually I've got one with a guy who's in Milan and he's 6 hours ahead of us. So all the time we'll have calls. They're after his kids go to bed and he's always beautiful and he doesn't want to talk. So we'll say something and if he wants to get back, a lot of times I'll just write something into our first side channel. So an app that's adapted will enhance or degrade grace delete based on the capabilities and choices that we've made. That's what we've adapted all along. Let's talk about being fluent. So conversations often start especially today with chat. I certainly don't, if I want to reach out to somebody the first thing I do is pick up my phone in a lot of cases. At least if it's a co-worker it's not. I'd like to start with chat. I want to see where they are and maybe ask a question. I just want to see if he's available. But at some point chat becomes too cumbersome so we'll switch to audio. So I want to be able to click a button that enhances that conversation from the same conversation, the same context from chat to audio. Maybe I want to pull a couple more people in because this discussion is getting bigger. We want to maybe invite a customer if you want to invite someone from the department. Upgrade the video because some things, whether the pictures tell the followers of the video as well as actually more in a second. But then when we're done we should be able to go back to chat. And the flow here is that this is still one conversation and I think Skype does this very well. You never had a Skype conversation where you started chatting and then went up to video in the background. You can kind of steal back in the history of the conversation. And of course frankly you need to switch devices. This is a big one. And not everyone really gets this right. Again I want to give Skype credit for this. I'm at my desk and I need to leave. I can actually transition that call to my note fairly easily. Being contextual, this is my favorite of the five. A friend of mine Jeff Longworth has this really great book that in the future communicating isn't what you're going to be doing. It's what you're doing while you're doing something else. This idea that we have dedicated communication devices I think it's that. I mean even all of us, the phone that we carry isn't primarily a phone. It's everything else, right? So being contextual is all about getting context into the conversation. Or putting the conversation in the context of what's happening. These are just some sort of not entirely random examples but examples of information that may be useful to your conversation. So how many colors are waiting in the queue of a context? How much are we sold in the past month? I like the one that says Apply Manager to this call because it implies not only that the manager can easily add it to this conversation but the business relationship is understood by the application. So if I make a request and I say my manager, the application is who I am who is my manager is, who is how to reach my manager and then actually add to the conversation. You can see this in text as well. So a good example of this contextual knowledge will facilitate the direct participants of the conversation. Also third party services. In this case you can see that we were talking about a problem with Astros. But you can actually see that notifications from New Relic were being pushed directly into the conversation. So that just gives everybody more visibility about whatever problem they were trying to solve. This is a great example of really business specific information. I made a conversation and I just, when I said this message all I typed was I wanted to know about A what to do to provide. But the application did is it actually went back, it understood that that was a special string hashtag so to speak. And it actually looked up that information from the database and registered some information alive. So this conversation now has not only what I said, but the context top what I said, very little effort for me. So this makes all of that communication much more fluid. Everybody is in the same pain. So the important communication is that absolutely you have to be trustworthy. So how can it be trustworthy? I think the number one rule don't surprise the user. Don't do something that they don't expect. One example that would be don't share the contents of the conversation with people who they don't expect that conversation to share. So if you have a conversation between two people, it's really important that you know what else to deal with, come back later and access that same conversation. It's really important I think as well to help users make smart choices where it's required. So there's been a lot of debate about as what RTC has matured, as the standards have gone first, as the browsers have adopted standards, there's been a lot of discussion about how to request permission, whether you request permission for the camera right above. I think here we're going to Google Hangout to start a Google Hangout. When you first load the page, if you've not been there before the first thing it asks you is can I ask for access to the camera? Now it does remember that, I'll get to these about that later, but it does remember that you've granted access before it drops into the conversation. You see a picture of yourself and it says, here's what you look like, are you ready to go in? I mean that's an important step because what you don't want to do is jump into a conversation or somebody loads a site and they've been to before, they've already granted permission, it takes you straight into the conversation and then they just realize that they're recording panics back to the arrays. So doing things, little things like that to try to help you always feel fully in control of their communication is really important. And that's especially true with microphones. At least on Macs, cameras kind of have that little green dot that tells us that it's on. Microphones don't have such a dot. So there are plenty of examples where an application is that can lead to some other application. Another item about trust organization's identity. So identity it's an interesting thing. There are lots of applications that make their name based on anonymity. There is the identity, that's an important use case. But for, I think the algorithm app having identity is core to facilitated communication. You want to know who's in the other end of the call. We take caller ID or different. When a phone call comes up and look at the number, and I can say well that's my wife. I know who that is. In reality, caller ID is actually very, very easy to use. So the only reason that we don't see a lot more of that is just because of basically the chargers controlling the network itself. But anyone who gets a certain kind of voice or a peak connection or a thing that holds your eye will be able to actually set the caller ID to whatever they want. I may or may not know that. But we have a lot more many more options for a certain identity. We have a law. We have social identity from Facebook and GitHub and Twitter. And we can actually use those to enhance the communication. And if your communication is built into the app use the identity that comes from your app to assert who the user is. And finally, these conversations should be referenceable. So referenceability is, I think, all about sharing. Every conversation in my mind should have a URL. This is an easy thing to do. We deal with resources and objects all I love to share. So every conversation with a URL that is permanent and unique it represents the latest state of the communication request. So if you schedule it wrong then you should generate a URL that says this call will happen. If the call is going on and you hit that URL really it should bring you straight to the conversation. It should present a user interface that lets you be a part of, participate in that conversation. Once the call is complete then you should provide some kind of transcripts. You have a recording of multiple content types. So if you record the call and you transcribe it allow the options to download the audio as well as search the transcript. Any images or leaks that were shared can be combined into that view. But this idea of a single conversation can be referenced by a URL in all its forms. And then whenever possible they get searchable and downloadable. Because you don't know something's there and you can't find it it may not be there. Oh and a question should be able to be shared. That's really one of the main points of having a URL. I can copy and paste it and send it to anyone. Assuming they have permission to view it you'll be able to see it. So those are my five tenets. I want to try to apply those. I've got three idea applications. These are not necessarily great ideas by themselves but I think they illustrate where you can take these these tenets and these tools and embed them to enhance web applications today. Kind of a silly one. A live, anonymous matchmaking service to think tender about the video. So I come to funny dates. You can kind of see we've got two people here who have video sessions going. They've got some stats and how they were matched just like they all like most moustaches and puzzles. But these people also really want a sense of privacy. They don't necessarily want to share as much information about what they certainly want to give off their numbers. So not only to be given the ability to find each other and communicate we've also given them these stickers that go with their face. You've probably seen something similar with Google. We can help them secure some of their identity by giving them these tools where they can still get a sense of who each other is, they can be voiced, they can see some of the expressions. But you can still hide some of that identity fairly if I can look at a tool like this. So what does this give you? If you save introductions with strict anonymity everybody comes to the site. The site overneals what it's designed to do. No need to exchange phone numbers. There's a very low friction to get a Google start-up. There's no app to download, there's no plugin to install. Really just by going to the site the entire area of communication with Google for identity. And then we use silly tricks that can be used to break the eyes or again to continue the anonymity. And if you want, we could do an upsell. Skype just did their language translation, right? We'll have to apply that to the site even by text or by audio. Alright, so the second example is an instant response app. So my background is before I became a developer I did a lot of ops. I did silver administration stuff. And this kind of thing, whenever something would go down you get that phone call at three in the morning or the sun's way down. Getting everybody in and on the same page would be a good challenge. So what if we could build something like this? What if we could build something that would enable people to not only discuss whatever is actually broken but also bring in contextual information that's surrounding the problem. So on the left you can see the chat. Just like before you can see where people are discussing the problem. And third-party services, the tan and green lines, third-party services are pushing in data. The content there is important, but it's the idea that anytime someone does a deploying you can see the plow is made. If there's an alert monitoring system you can push into that text chat. On the right you can see the voice and video conversation going on. And of course the people who are doing my video will see each other. But there's nothing to say that they couldn't get close to me by mobile device by either my telephone call or my mobile app to stay a care of their car. Now what's really interesting, what makes this different than just any other communications app is what's on the bottom. So what's on the bottom is charts, graphs contextual data from the monitoring application itself. So rather than waiting for an event to come in I can actually see trend lines happening in real time as part of the communications tool. So the way I envision this is that someone a company builds monitoring tools, goes and builds this into their bashful. I will not give it to you. Whoever does this. So the key here is timely contextual information. The view itself can adapt if you're on a mobile device you'll get a more focus on the communication and less of the bashful type features but on desktop they'll get the full experience. I like in particular the emphasis on group-based communication. So I look up and everyone in the ops team gets an invite to join that particular conversation or context about that conversation. But more importantly if I need to bring in a vendor, maybe my storage vendor needs to jump in the conversation I don't want to give them a user account in my system for that purpose. We can generate this unique URL from how I took it from straight to that page and he can join in that conversation and see what's discussed there without exposing any of my other conversations too. Of course we can better connect to our services we can push in data from get up or do like whatever. We can also record these instances and learn from them later. So once you record it we can actually tag back to our issue tracking system with a link to this conversation. So if something signals down right breaks this in a similar way, someone does a search and finds it you can come back on this original conversation and understand how this could result. My third example so imagine you have this very simplistic looking website and you want to see you've been to the alcohol artist you want to see the advice the alcoholist gave you. So you actually see this from both of them so you call the alcohol artist you talk to him and he gave you some advice. So the call was recorded that recording is available for you as the patient to download this site. The transcript of that recording is there as well and the doctor is actually so last time I talked to the doctor he used some words that I thought I knew how they were spelled and I was wrong and he was in this case he would actually write them in and I'd be able to find out the information on what those things are. In addition there's another button here I've got a problem with my bill or if I need to talk to another alcohol artist I've got a urgent problem. I can click the button right here and immediately be connected with someone who already knows who I am who has access to whatever information I initiated the call, whether that's a bill or medical information and I don't need to keep track of this phone number I don't need to keep track of any security information I think in particular the identity part of this is interesting because if you call your bank and they ask you for the same free piece of information your name, your account number and the last word is in the social and anybody can fake that right but if I have a secure authentication in this website and I log in with my password they have two backfire authentication and they're frozen in the future that strong authentication is carried through to my voice conversation so when I click that button and whoever takes my call takes my call they don't need to talk to it much more at the same time somebody just memorized my social security so the medical advice you face secure for our authentication I think is one of the big deals here maybe even verify you can do voice biometrics make sure that the person who's calling sounds like the person you can even cross check against location which is not something you can really do and then you can automate the claims so you've got the recordings and transcripts to the patient as well as to the claims processing people any of the medical advice that's given so that long string of things I should do three times a day that he gave me it's all goes into the file I can go back after and read it it also gives you an easier way to do auditing and service quality assurance okay, I hope I'm out of your sleep I have a demo so this moment to see things pretty cool and I thought that if I could show you it would be cooler we have as you can see I've got Firefox running I built this really simple little scenario app and all it's done so far is connect to this page so this is an example of whether you see requesting permission from the camera you may have heard me earlier mention that sites will remember this preference the standard has fallen upon the idea that if a site is not using HTTPS then it forces to request every time so I'm running a snapshot of it there's no certificate so I have to fix that if this were a site that had HTTPS and everyone should remove it does then it would remove it so this is Chrome so I've got I'm sorry this is Firefox I've got Chrome over here I'm going to bring up the launcher and that rocket launcher has a camera on it now what we have is I'll show you the Chrome so Chrome is right here you can kind of see the video coming from Chrome it's being transmitted to Firefox now both of these browsers are running the global most so the traffic is actually only going through the back even though the server is also running the other thing I've set up is Google has this really cool speech JPI and they expose it there's a drop-through library called on-yong and on-yong is constantly listening by just listening right now if I do it right now it's probably going to blow up more of me but if I say that it should actually activate the launcher then I should be able to talk to the launcher to steer it and fire it so let's see what happens what on screen move left move left I should have made it go further how much for that since this is dangerous demo move down but the communications here is the video is obviously WebRTC the audio is actually using a different browser extension not a browser extension, excuse me a different JavaScript API that is Chrome only the particular recognizer I'm using right now is Chrome only but speech recognition can be done client-side or server-side if you're using WebRTC you can very easily call into something like and then the last piece of it which is just to move the launcher there's really nothing more than a curl or in my case just a jQuery API call so that's really it I mean it's to nothing but to do it so that's pretty fun so with that, that was my presentation on WebRTC I have a few resources for you if you'd like to know more about WebRTC the first link in particular is great it's what I used primarily when I was setting up my demo it's the official set of samples from it's the official set of sample code from WebRTC.org it's on github a lot of the demos are alive so if you go to this page we will look through and actually start the video and then our demo includes the link to the github the source is on github the WebRTC.org itself is sort of a central point for WebRTC resources I also want to point out an initiative run by a friend of mine called WebRTC Challenge and his goal is to get 1 million developers who are using WebRTC by 2020 it's a pretty obvious goal I think you can do it he's got some pretty interesting content a mailing list, highly recommended a couple things someone mentioned as well is this big RailsConf if you're interested in doing more voice with Ruby definitely check out the Rails like framework for voice I'll also point out RubySpeech if you do get into some of the more interesting speech recognition scenarios RubySpeech is a library we're generating the markup needed for driving synthesizers and web-founders it makes that whole process a lot easier the last bit is my contact information I've been playing, got the plan to work some quicker at github and of course get your new learning but with that you have any questions I would love to have you Yes, go back to your medical one where you talk about your own core what's the connection between peer and peer and how does that save time the question is an example with medical reporting if WebRTC does peer-to-peer encryption how would the call be recorded so the answer to that is WebRTC can be peer-to-peer but it doesn't have to be peer-to-peer so I kind of hinted at this earlier when I said that peer-to-peer encryption is built to enforce that you can this is what I'm going to explain is that if you have a media server in your network it will participate as a WebRTC endpoint so instead of going direct from peer from browser to browser it's a free switch and then in that case because you're being coded on there yes, how do you handle the use case where the person on the other end steps away from the computer is not a computer or whatever do you have options to route over playing the telephone or just take a voice message or what are your options at so the question is if user steps away from the computer how do you deal with that I guess they step away from the conversation or during the conversation maybe they're selling something on some site and they aren't using media but the person on the consumer wants to reach that so you try it's almost like a contact center scenario where the agent is walking away from the desk so in that case I would probably make sure that the call that comes in gets routed from something that can be more intelligent in the series so it might try WebRTC first and then after five seconds if that's the work, either try somebody else now the Astros can pre-switch our mode open source to let the agent if you take that call and WebRTC from the client side once you get it into either of those it can be converted to almost anything it can be converted to more WebRTC it can be converted to standard SIP standard SIP or some writing or even to regular telephone network calls so the same kind of rules that apply are hunting down untaxed areas that would apply in that case as well so in this case there are some motion detection libraries from an upstream that will actually if you wanted to detect presence by looking at the room and everything but basically anything you would do to detect session activity and timers anything you do to detect a user's presence on one end can be used as input to some other decision making and you can correct it so that's the question any other questions? so what are the risks of that what we want in this case? to detect that what is this location? so are you asking you're asking about the IP you're asking are you getting the first IP address or I guess location based on the information you're getting you could so if that particular remains what you would have to do is you'd have to control the negotiations in two years such that you'd be stripped out first and then apply all the information you'd have to only leave the part of the server side to protect the other it could be done if you're putting untaxed areas and how strict you're alright I'll finish my time thank you very much