 So my presentation here is basically a good transition from what you've heard in the morning with all the other speakers talking about the user experience and so on and so forth. So what I'm trying to talk today is basically the lessons and the tips that we have learned by powering WebRTC into the enterprise applications and optimizing the customer experience using WebRTC. So a quick show of hands on how many of you recognize the word CX? All right, not surprising. That's good. So when you think about UX, that's user experience. But when I talk about CX, that's basically the customer journey through your app. It's like some total of the customer experience as the customer goes through the app and experiences different things through the app. So what do customers expect from great experiences? So they expect consistent voice, video. The data is everywhere. So aggregate the data and make it a personalized journey for the customers and connected interactions. So that in turn will give them a very rewarding relationship with your service and with your application as well. So today I think we've had speakers talk about the customer service applications. We have speakers talk about the health care application. So any kind of applications works very well with WebRTC. So either health care, insurance, customer service experience, and so on and so forth. But I think, yeah, I skipped one. But the customer journeys are really complex. So we have seen that you can definitely use WebRTC for a minimum viable feature set, like video, voice, and what have you. But there are multiple devices, multiple networks, and multiple channels. So taking the customer seamlessly through the transition journey is not easy. So basically any broken journey, any journey that is broken here drives customers away. So data shows that if the customer has a bad experience like a patchy video or a bad audio once they come to your application, it is 91% very likely that they'll choose an alternate service. So that's where the customer experience becomes very important. And it's one of the top priorities for all the enterprises today to have a seamless journey and provide a very good customer experience for their customers. So the tip one is enable seamless journeys. What does this mean? So I think in the very beginning, Sahi talked about the web angle of WebRTC and the wipe angle of WebRTC. So whenever we talk about WebRTC, we talk about this paradigm shift. So paradigm shift from communications as a silo to communications as a feature in your web application. But that comes with a certain challenges as well. Because if you are, like me, very impatient, you start pressing the browser reload buttons whenever the call doesn't connect or the call freezes or the video freezes. What do you do when the page doesn't come up in the web browser? You reload it. So there are web style browser reloads and the classic back button. And of course, the native apps do crash sometimes. And there are connectivity changes, Wi-Fi to 4G, device handoffs, and server side failures. Of course, nothing here the customer cares about. All the customer cares about is basically the experience that the customer would have. So what we have done is we have solved this by the concept of session rehydration. So basically it is to keep the session alive when the connectivity is interrupted and recreated as soon as the connectivity is reestablished. So what we have done was, I think, three years ago when we started building our product, which is WebRTC session controller, we were looking at the drafts. And there was a draft IETF RTC web draft where we got this inspiration. So basically, I think the session rehydration didn't make it into the final state because maybe my guess is it has a lot to do with signaling and how reliably the signaling is implemented. But we took this concept and we built on it. So what happens is, let's say there's this client and the server. And for some reason, the client goes down. And the client has to reconnect to the server. So what we do is, when the client is trying to reconnect, when the client goes down, on the server side, we still keep the session. So we still keep the WebSocket session. And when the client is trying to reconnect, for example, maybe the browser crashes or the browser reload, when the client is trying to reconnect, we have some session ID, some information on the client that we store. So that session ID is passed onto the server. And the server detects that this is the session ID with which the WebSocket connection has been made earlier. And then it resynchronizes that session ID and it recreats the WebSocket. So basically, we built a very reliable signaling protocol. It's called the JSONRTC protocol. So basically, that's based on WebSockets. So it does a complete resynchronization. So it has the reliability built to the message level. So whenever the client comes back, so it resynchronizes the client messages and the signaling is re-established. And then you have the ICE procedures. You send a new STP and the whole Shebang to get the message working. So what does it give you? It gives, from the customer perspective, your connection. It's a seamless journey. So even if your app crashes and you bring the app back, it shows as if nothing has happened. Maybe there's a little pause on the RTP side because RTP is generally UDP and that's somewhat expected. But it's very unnoticeable, I should say. And then I do come from VoIP background. So when I compare the VoIP call setup times with the web's call setup times, I do find the web setup times are a little slow, or maybe it's just me. But fast call setup times impact customer experience. So customer expects the call setup time to be really fast. And WebRTC has this call setup procedure that takes considerable amount of time to establish. And why not? Because there's a lot of thing that is going on. You have to gather the candidates. You have to prioritize the candidates, exchange the candidates with the remote party. And then there's connectivity checks. And then finally you get the candidates that you connect with. So there are multiple ways this can be solved. And I think most of the people now are talking about dynamic media peering. This is where you prioritize candidates that are most likely to work first. Then you establish the connection with that relay candidate. And then at the same time, you try in parallel with the other parties that can communicate directly. And if they can, you switch the media. So alternately, there is the strickel ICE that reduces the time for ICE procedures to complete. So basically it is an extension to the ICE protocol. And it sort of reduces the time because it incrementally does the candidate gathering. And that sort of optimizes the call setup times as well. So customer experience is tip two. So identify and solve the weak points. Solving weak points is one thing. But identifying that is a more difficult thing, actually. But so don't be afraid to step back. And I think we have heard this over and over again today is if the call drops in the middle of the conversation, that's one thing. But if there is a patchy video, that's a big no-no for the customer. So how do we solve this? So there is a good WebRTC stats API that can measure jitter, packet loss, the bit trade, bandwidth. And of course, this might give you some after fact data. But then you have RTCP feedback mechanisms from which you can calculate the quality of your stream. Then with the frame rate, you can find out if the CPU of your device can handle the video and also the battery. If your battery is really down, you wouldn't want your customers to connect to the video. I mean, you can either trigger a message or say that you can fall back to audio. So there are different ways you can do that. And of course, it need not be audio. You can switch from an HD video to a low-resolution video or audio depending on various factors. So it's basically aggregating all this data and triggering some sort of a message that the application can catch and provide a seamless experience to the customers. And of course, now we have simulcast. So basically, you can encode the same video stream in different resolutions so that you don't penalize both the parties. So you only send a low-resolution video to one of the parties, and the other party can have a good HD video or audio or whatever it is. So I think we have different other speakers talking about simulcast and so on later today. So I'll sort of step this. And one thing I noticed is WebRTC notifications. And I didn't hear many people talk about it, but from where I stand, it's very, very important. So the customers expect to stay engaged when they're vandered away from the app. And they want to stay engaged without draining the battery. So there are multiple things you can do for this. So basically, from my perspective, whoever is handling the signaling should also handle the notifications. So you can optimize the WebSocket connections with push notifications. So how does the battery drain? So you have the client, you have the server, and the client is always pinging the server or letting the server know that I'm alive. And that will take up a lot of resources, and the battery goes down pretty quickly. So what you can do here, so you can optimize the WebSocket connection. So basically, the client can tell the server that, hey, I am hibernating for a while during the period of inactivity. And the client can go off. The WebSocket connection is broken. And on the server side, the server can keep that connection for a while. And whenever there is a message coming or incoming call coming in for the client, the server can rehydrate. Again, I'm talking about the concept of rehydration here. Basically, the server can rehydrate the client session, wake up the client using a push notification, and resume the call. So there are many ways you can implement the push notifications. You can directly connect to the APNS, GCM servers, get the notifications, or you can use the mobile. You can create your own push notification gateway. Basically, it can connect to multiple notification services, and it can register multiple apps, and so on. And of course, Chrome has push notifications as well. So we have Chrome push notifications based on W3C API and service worker, which works well on the desktop, as well as on the mobile browsers as well. And finally, I was thinking whether I have to talk about this or not. But sure, certainly we do, because we all like elephants, and especially the big ones. So interoperability is a key to success in the enterprise applications. And from where I stand, almost 60% of Oracle Enterprise customers run their desktop applications on Internet Explorer. And Oracle has a big player in enterprise application space. So how do we solve the IE stop gap on the desktop? So we did use the flash fallback solution for a while, but now I think our customers look with a funny face when we talk about the flash fallback. So I think in the interim, there are IE adapters, IE plugins that you could use for multiple versions of to support the multiple versions of Internet Explorer, because that's a funny thing, right? It's not one version. If you look at some of the enterprises, banks, and some insurance companies, they even go back to very old versions of IE, maybe six, seven, whereas until IE eight, even web sockets are not supported. And then wait for Microsoft Edge. So Microsoft Edge is now supporting GetUserMedia. So probably we'll hear about what and when in the session that is coming up with the Microsoft folks. How about Safari? I think that is a question. So I think on the Safari side, the stop gap is hedged with various things. So we have the native iOS WebRTC support, which sort of hedges that as well as, I think, people can use Chrome on Macs and so on and so forth. And then finally, mobile is different, and we all know that, right? And customers do not like if their video call drains their battery on their device. So certainly, I think if you're talking, if you have a video call set up for 20 minutes and your battery goes down south, definitely that's not a good customer experience. So hardware acceleration is very important, especially if you're working with applications where customers use them mostly on the mobile devices. So video coding with dedicated hardware is always better, has better video performance. And if you're really working with good quality videos, 720p, 1080p, hardware acceleration is very, very important there. So Chrome 45 has started to support H.264 as well. So that's good, because there always has been a big gap between the number of devices that support H.264 hardware acceleration versus VP8 hardware acceleration. And that certainly was troubling us quite a bit. So stop gap, I think, certainly you can fall back to H.264 when VP8 hardware acceleration is not supported by the native chipsets. So I think WebRTC could provide some sort of an indication that this device has VP8 acceleration set up and sort of switch back to H.264. Or there are APIs on the native devices which tell you whether the hardware acceleration is supported for the codec or not. So VP8 H.264, we have been struggling with these so far. But now I think we have new candidates in the mix. And certainly I think we are very excited to look forward to what comes in. So I want to conclude my talk saying that customer experience is very important. There are many more things that we have learned. So I'll be very happy to share my experiences after this presentation as well. But I just wanted to close with this code from Macy's store manager, which says, be everywhere, do everything, but never fail to astonish the customer. Yeah, so now I want to transition to my demo. Amit, it's going to do a quick demo. So why don't we, while we're getting set up here, we have time for probably one question. Questions? Serge, any indications from your customers on whether they will move from Internet Explorer to Edge? It's very difficult, especially I think, when these enterprise applications have written their own web pages and websites that are very specific to a version of Internet Explorer, I think they sort of stick to that version. So I've talked about the session rehydration, right? So how the session gets recreated during browser reloads and so on and so forth. So I have a quick demo here that I want to show that shows a user logs in into a room-based service, and we have a lot of them right now. And let's say I'm a user, Alice, and I log in into a service, and I create a room, and I'm here. So now I take this URL, and I give to my friend, which is me, again. So let me open the site again. Open another window. Actually, it should give me a moment. OK, maybe I should. OK, maybe we can do that as well. So let me, so now it's OK. So I become Bob in the next window. So now we have Alice and Bob finally. So we have the call setup. So now I also have a chat service. So Bob says hi. That comes to Alice as well, and Alice says hello there, and that comes to Bob. So now Alice, for some reason, wants to reload, and then the connection gets re-established without any delay. And you see the voice call gets re-established. You see that the data channel gets re-established. So everything gets seamlessly re-established with this. So I just wanted to show this quick demo. All right?