 Okay, good evening everyone and welcome to my hometown. So last year I I did start this meeting myself With friends with my friends from Qovis and all the sponsors and I'm really happy to see that these events is working organically and taking its own life Just wanted to say that my name is Victor Pasquale. I've been involved in WAPRTC From the very early days since we started the initial both meeting at the ITF and then doing some Back-and-work with Google, Ericsson and some companies on that and I was invited today to just provide a very quick like 10 minutes or 15 minutes standards overview, so You will have to suffer across this before going to the to the beers so There is a good sentence that I always like reminding myself when I talk about standards Is that the good thing about the standards is that there are so many that you can choose from So this is one of the beauty of the standards. Well, this is the typical joke about the standardization This closure I do work for Oracle, but all the nonsense and stupid things I say today are just my own fault Nothing to do with my my company Yeah, who's somehow related to WAPRTC standardization or know what's going on where? So basically there are a number of players Which are involved in the in the WAPRTC as seen some are providing value some others Just want to be part of the picture just to get some press releases So hopefully today we will have some consistent discussion So basically the the two organizations which are developing the core work on WAPRTC are the ITF Which is the Internet Engineering Task Force and the W3C So today I'm going to go in a deeper detail on the ITF as we have here Dominic Who's working on the W3C so basically he will provide very good insight on the APIs that W3C is developing then we have those guys that are taking the Technology that the ITF and the W3C are producing and are trying to incorporate this technology into their existing architectures And this is what the 3GPP is doing So we'll go over what 3GPP is also doing on that and then we have a number of organizations which are also doing some some Activities around WAPRTC There is something I would like to highlight which is the GSMA and here we are happy to have today each one And these guys are spending a lot of time Try to understand what is the role of this technology in the service provider space and how to monetize these and what is the value Operators can get from that and basically I'm sure that each one will be able to share today very good information on that aspect So when it comes to the W3C, I say I mentioned Dominic will take care of of this So basically they are working on the peer connection API, the data channel and get user media There are some discussions about the RTC Whether they should be depending on SDP offer answer or not Dominic, I'm sure it will provide a very good explanation on that But basically the R3C is defining the APIs that web browsers are implementing and exposing them To JavaScript developers and so they can get access to the older W3C capabilities Then we have the ITF which basically means flying somewhere an entire week drinking a lot of coffee having some very strange discussions and then Not getting any consensus and then having to do some mainly these discussions afterwards This is basically my experience with ITF. We're basically at the ITF The work we have been doing is defining the protocol stack for WAPRTC So the W3C as I mentioned they define the APIs that web developers that they have in some cases no clue about Real-time communication. So basically there are a number of APIs. They are producing applications And this is all the magic which is happening underneath the APIs in terms of Get me this codec or open this port for sending encrypted media, etc So basically what the ITF is defining is which are the codecs we are using How is the encryption working on on the audio and video plane? How is the key exchange mechanism for doing this in a secure manner what are the security threats for that? What is the forward error corrections that we should be using for WAPRTC, etc? and if you guys go to the ITF website for WAPRTC which is called RTC web You will see that there are a number of internet drafts which have been already discussed for a while. So here There are a couple of documents which have been already published as RFC. So basically at the ITF what you do is You write the internet draft which is this strange ASCII document with strange diagrams This this document is discussed and then if there is agreement in the working group It gets out by the working group This is the usual path and then when it gets up to the working group then it finally gets published as an RFC So so far we have published as an RFC The use cases and requirements for for WAPRTC. This is basically the one of the very initial documents Where we were discussing. Okay, so this is what part is he think what is this really about, right? then there is also an RFC publish on the standard content freshness basically this is about how the standard traffic can be sent or not based on the authorization and etc and Then there are a number of documents which are here. You can see the RFC editor skew These are documents which we already have agreement. Okay, so this is ready to go And now we need to flow like a process before it gets published officially as an RFC So here you can see basically the two specifications about the data channel So the group RTC is not only about voice and video We also have a peer-to-peer capability which is a data channel which runs over a CTP PLS We don't need to go into details But basically here is where you see the details for for this protocol We have another document which is how you use RTP here So you guys most of you are operating seed based networks, and you are using RTP So here we are defining. Okay, what is this profile that for RTP that we should be using? Is it using also RTCP feedback? Should it be also encrypted? Shall we multiplex that into the same port? Shall we use different ports? So this is where we are we are defining that and Then it's also the video document Which is basically defining which are the video codecs that what parties you should be using if you have been following the Discussion we had lots of lots of discussions around. Okay, so whether we should be using VP8 or H264 when at the end of the day I like to explain this at some later some lawyers started coming to the idea And then we realized it was not a technical discussion anymore. So it was such as a royalty discussion We had some battles back and forth and then the final conclusion was that both VP8 and H264 should be supporting for For what party see but my personal feeling is that well This is just a starting battle because now we need to to discuss about H265 and VP9 and what's gonna happen beyond that So basically it's just the starting point Then there are some other documents which are in the IHG processing Which means the kind of the clever guys of the ITF are reviewing before approving these documents to be published as a as an RFC First of all, we have the RTC web audio basically here We're defining the mandatory to implement audio codex for what party see the agreement is to use 7-eleven and Opus We decided to do 7-eleven for backward compatibilities But in most of the cases you are seeing in the plamence Opus being used But then some folks from the telco industry being led by Orange France telecom They did publish also a document which is basically defining what are the okay So we are using 7-eleven and Opus But are there any other codex which might be relevant for some scenarios like mobile networks or access to IMS networks, etc That might provide kind of recommendations to implement other codex beyond that like 7-22 or some other codex Which are being used in in mobile network So basically the RTC web audio is defining what's mandatory to implement and Audio codex for interrupt are defining Okay So these are the recommendations that you might want to implement this if you need to interrupt With some of the domains and you don't want to do a transquad There are also a couple of documents right by here on security Basically analyzing the security threats for web RTC. What is the architecture the identity provider? Role in the architecture, etc And then there are some other active drafts which basically are the ones which are having more discussion Some are more major than others and so at the top We have the ALP and which basically is a mechanism for letting you know a middle box Like would be an HTTP proxy or firewall saying hey, this is gonna be a web RTC call Please let my media go through this is not working yet in the real world So this is something we are working on but there are some other mechanisms today being the platform for this there are some other Documents are finding the constraints. This is the interaction with the get user media API There is an overview document Basically, I wanted to provide an overview of these are the core documents from the ITF perspective And is there anything here that you guys are missing? So All I have explained here has to do with media right nothing to do with with signaling here We have discussed about the codex the keys, etc But nothing to do with something with signaling and the point here is that what party see does not find It does define how the signaling layer should be interacting. This is the reaction from some of our customers when we tell them So we define in the jsep how the signaling plane should be interacting with the with the API, etc But for what party see you can use HTTP. You can use see if you can use XMPP whatever protocol you might want to use for that This is what it comes from the ITF. So basically what I wanted to point out is that W3C Dominic they are defining what are the API's that what developers are using The ITF is defining the media profile. This doesn't need to be a browser could be a mobile application could be a Fax if you want to call it So this is basically a media profile that any device Preferably a browser should be implementing in order to be what party see compliant And then we have the interaction with the signaling server and then on some of our peers Which is not defined. So basically you can take what they were you feel comfortable with there are some standardized Mechanisms like sick web sockets or XMPP web sockets But we are for instance at Oracle doing JSON. So it really depends on what's the scenario you might be using And then finally to think that I'm running out of time The 3GPP which is basically The group that created IMS. I'm not sure how many of you are familiar with IMS But this is the foundation for both the voice of our Wi-Fi and other solutions This is really really complex if you really want to go the 3GPP path Fortunately some means we have simplified this to make it work And basically if you take a look at the IMS architecture with support for what party see There isn't anything really really new. So basically We had in the past something called PCSF, which is basically the signaling server now in order to include what party see support We just put any in front of that and this is enhanced PCSF We had in the past something called the IMS access gateway Basically, this is the media and the media node for for for IMS We put there yet another in front of that doing all the all the functions for like TTLSSRTP termination Transnace coding, etc. So here this is how it fits into the architecture and then there are new components So for instance, you can see not of the WSF, which is basically the web server that you are using and there are other components in the back end like the WAF, the web party see authentication function which basically Guys from QoVis are implementing which basically is providing interaction from what's happening in the access network And what you guys have in the core IMS network like in the HSS, HLR, etc And this is pretty much from the ITF and 3GVP perspective. I hand over to Dominic. I'm sure he will provide insight on the Thank you Okay. Hi everyone. My name is Dominic Azal-Mathieu. I work for the WCC, the World Wide Web Consortium, and in the WCC I'm in particular responsible for Getting the webRTC APIs to standardization, which hopefully will happen at some point So you can reach me at www.org. You can follow me on Twitter as don't call me Tom and Very quick introduction of what WCC is. So WCC is a consortium. We are a membership-based organization We have more than 400 members from a big Set of the industry both big and small players We have obviously all the big names Google, Mozilla, Apple, Microsoft and so on But we also have plenty of smaller enterprises. Everybody in WCC has The same rights so that's a fairly empowering Organization. WCC was founded by Tim Berners-Lee who I hope most of you know Created the web some 26 years ago WCC works mostly with contribution from its members, but it's also animated by a staff of some 80 persons from which I'm a member of So we have offices in Europe, US and Asia So WCC is the organization that creates and develops standards for the web So I'm sure you've heard about HTML5, CSS, a lot of JavaScript APIs Some of the specificities of WCC in the standardization space is that we ensure that all the standards we bring to the web are Reality-free what that means is that if you create a browser if you create a web application You don't have to pay anything to anyone and I can tell you it's not always very easy to keep that commitment But we do our best So my particular job in WCC is to ensure that as I said web RTCs API, as Victor described the ITF deals with the protocols and WCC deals with JavaScript API in browsers So my job is to make sure that at some point this API is stop changing all the time Sure, some of you have had to deal with some of the Rapid change in the API you found in implementations and I'm partly to blame for that. So sorry So I'll Wanted tonight to review some of the APIs that WCC has been working on just to give you an update on where they are in terms of development and also maybe to Inform you about what's upcoming in this space that might be of interest to you So obviously the first thing you need if you want to establish Video audio communication is access to the microphone and camera. So that's get user media API for those of you that are developer Knocking woods it should get to candidate recommendation very soon What can be that recommendation means is that we basically are not going to change anything to it We just have a couple of issues to close but that