 So this is an update, actually, representation that I made last year. So last year, I had to introduce Janus for the first time. I don't know if everybody here is familiar with Janus or not. I mean, there probably won't be much time to explain what Janus is in general. So I referred to the presentation I made last year for my information. Just as a quick introduction, it's basically a WebRTC server that will seem to be pretty much involved in our way. It's all open source, and I get to know how to do that. There are demos and documentation in an active community out there for you to play with. And just to summarize it a bit, we have a WebRTC core that is part of the Janus story itself. And then we have different plugins to different things, specifically how you can transport the Janus API over different transport protocols, actually, and how you actually want to end on the media. So whether you want to use an SFQ and a loop bridge, or all of them together within the same applications by doing some combination on the right side. So that's basically what Janus is in a nutshell. And here is a quick link to this life of last year. We're interested in knowing more. This presentation is more about how you can actually monitor and troubleshoot what is happening within a Janus instance in particular, which is far from general. And as the first presentation showed today, it's hard sometimes to find out what's wrong in a WebRTC core for some reason. And for a while, we only had a single way to do that. Specifically, our item was because the admin API, which is basically a request-response kind of protocol, where you basically query Janus with respect to a specific kind of a specific peer connection for information. And we will return a bit of stuff out there, the results will drop off the right track with a bit more in detail how you can use this information in order to troubleshoot a peer connection. And it typically works as you can imagine as a polling protocol. You know, Mike, do you want me to explain it now? OK, sorry. Is it OK? I mean, the real stuff is just going to start now. So you didn't miss anything. And then it really works just as polling really does. So at any time during the peer connection, you can ask Janus for information. It will return a snapshot of whatever is happening in there, so how many packets were sent, what's the current state of eyes, DTLS, all those kind of things. And if you are familiar enough with all of those things, you can have a look at those snapshots, maybe one or more snapshots in time to figure out what's going wrong, which, of course, is far from the ideal solution. I mean, this is just a quick view of how this information is returned. So it's split in different parts so that you can actually study different pieces of what's happening. What would be more interesting is that kind of an asynchronous approach. So something where you actually Janus notifies you in real time about whatever is happening either within the core or within different plugins, which is actually what we started working on some time ago. And we call them event handlers. So basically all the core plugins can generate events and there is an internal mechanism within Janus that then broadcasts these events to different new plugins within Janus that can then handle these events in different ways. And so as we'll see later, you can use these plugins for different things. So one plugin may save to a database or other plugins you may use for different things and so on. The idea is that it's not the event handlers that provide the trouble shooting, they just provide you with the means to actually either integrate with existing platforms or do the stuff yourself in order to do something more creative. And I'll also talk a bit about the sample event handler that we implemented in the meanwhile. And so the idea is that internally it pretty much works this way. So Janus generates an event, there's an event manager within Janus that relays these events to all the plugins that are registered within Janus to receive these events and then each event can do whatever it needs to do with these events. So one may just format the event to JSON and send it via HTTP to something else for processing or it may save to database or it may populate a CDR of some sort of whatever you need it to do. I mean, it really is up to what you implement in your own plugin there. And there are different types of events that you can generate and subscribe to really much, pretty much depending on what you want to troubleshoot. So if it's just session related stuff or if it's anything related to the WebRTC setup or statistics in real time and things like this, we'll see a brief example of this in a minute. And the idea is of course that each of those events which of course presents you a partial view of what is happening can then be used together with other events in order to correlate and have a better picture of whatever is happening also, let's say within the context of a conference rather than a single peer connection just to make a single example. And to make this easier also to integrate with other platforms we started writing a single event handler for the moment, it's the only event handle that is currently available. Hopefully this will change in the future. And this event handle does nothing more than getting an event that Janus originates, format it to JSON and then shoot it out via HTTP to an external backend so that in this external backend you can do some fancy stuff with it. And so it does, it is a bit much smarter than this, we can aggregate events so that you do not shoot a single message per event and something like this, some basic or transmission mechanism or authentication and so on, it's nothing more than that in principle. It's really just a way to take this event, shoot it somewhere else so that you can play with them in a nice way which I will also try to describe a bit in some examples and blog posts. And if we refer to the previous image where I mentioned that admin application that was calling for information in this case, the admin application is notified in real time whatever happens. So anytime a session is created the admin is aware of that. Anytime something happens, whatever you see wise it is also being notified. It is notified about any offer that happens, anytime the ice state changes and things like this so that you are immediately aware of whatever is happening within the platform which would make it easier to be monitoring and troubleshooting things on top of that. And the nice thing about this first interaction is something that is actually related to the presentation you'll see later on. In fact, Lorenzo is going to talk a bit about how they use these events to within the Homer framework in order to monitor a Janus framework which was really exciting and interesting for me. And I won't have too much on these in this slide but I just wanted to say that I'm really excited about this for several reasons. Most of all because Janus and Homer are both figures from mythology which is something that I really like about. But most importantly, I'm from Miteco or Miteco how people call it. And we call it Miteco B which means awesome in English. We called it like that also because it's what Homer Simpson says in the Italian version of the Simpsons anytime something exciting happens. So it's really like a match made in heaven for us. And you can, there's a YouTube video over there. Let's use it. So just to show this a bit more in practice I didn't really make some demos up and running but I did make some dumps in order to show you how this all works, at least from an events perspective. And I studied a couple of different demos within Janus. So we have different demos to showcase different plugins. And this one shows my ugly face trying an eco test demo. So whatever I send to Janus is being sent back to me. So we create a single peer connection that we can monitor. And so I captured some dumps of the event and the mechanism in order to see what Janus is actually telling me about whatever happens. And it is also summarized in a blog post that I wrote some time ago that shows how I actually wrote a simple Node.js application that gets all the events from the sample and the plugin as a JSON object and then saves these events to a database formatted somehow so that I can then make some processing over the database or the tables to see if I can get some information about what happened during a specific session. And so if we look at the events that are formatted as JSON as I said, we get a lot of events about anything that happens. In this case, we see a session as being created using the HTTP transport in particular. We see a handle has been attached to the eco test plugin and there is also this piece of information that is actually very important for correlation and I'll show this in the next demo that I'll show after. After we created a handle that is basically an abstraction of a connection between a user and the plugin, we can create a peer connection over it which is exactly what happens in this other event. So we get an event saying that the remote peer starting sending us an SDP and offer to basically create a peer connection. This gets passed to the eco test plugin and the eco test plugin sends back an answer to establish the communication which is exemplified in this other event that we get here. So the owner is local because it's basically the SDP that John has generated for itself. In this case, it's an answer. So as soon as the offer and answer has been exchanged the actual peer connection setup starts which means that we start getting events about the ice state machine. So whatever starts happening within ice. In this case, for instance, we might get events related to ice that is in the connecting phase. So the ice connectivity checks start taking place. After this, eventually the connection succeeds from a nice perspective and we are also notified about the selected pair that has been chosen for that specific peer connection which may be important for several different reasons. Once ice has been done, we come up to the DTLS information. So after ice is done, we still need to do a DTLS send shake to exchange the SRTP keys. So even in this case, we see that DTLS is still trying and that gets to a connected phase. If this doesn't happen, we know that there is something wrong, for instance, in the DTLS send shake and so gives us some ideas about why something is wrong in the connection setup and so on. Once this is being done, media starts being exchanged and so we get the events on that as well. So first of all, we are told that the peer connection is up from the John's perspective. We get information about audio and video that are being received by John's which is also important because it means that John's is getting now media from the user and so can start using it. We also get live statistics about H-second or so for each peer connection so that you can, for instance, see live statistics that tell you about the packets being exchanged and things like this and so may be useful for several different reasons and these happen for both audio and video. So all kind of information that as you can imagine are really important for understanding whether or not the peer connection is actually doing its job or not. More importantly, this is also important for the next demo. We also get event from plugins themselves and considering that plugins may be written by third-party implementers by whoever, they are very much plugin-specific as you can imagine. So we just provide a framework for allowing plugins to notify you about anything that happens within a plugin. In this case, the Echo Test user was just adjusting the bitrate settings to force a different bitrate for the communication so nothing really important. So if we want to look instead at a more complex application like a media conferencing application maybe and here I am talking with myself because I don't have any friends. Just kidding, of course. This is also explained in another blog post where I tried to explain a bit how things work. In this case, we were more interested in knowing whether or not we can figure out the relationship between peer connections belonging to different users. First of all, if we are able to associate peer connections belonging to the same users to a specific user and if we are able to reconstruct the topology of the video room. So who is subscribed to who? Who is publishing and things like this? Which is basically what the next dump tried to provide. So I will not go through the same session or webRTC event. We assume that everything is fine in that sense. We focus instead of the plugins generated by the video room plugin which give us some context about what the video room does with the subscriptions in principle. So in this case, we see that this session handle combination has a participant joined. In this case, it's called Chitro. Chitro is one of the users I always use in my demo. He has a specific ID in the room, one, two, three, four. So I know that this handle is being used to publish the contribution by Chitro in the room. At the same time, people instead is using those session and handle combination to publish his own contribution in the room. And then we see different events related to subscriptions. Instead, we see another handle being used to subscribe. In this case, this is subscribed to feed 83, something that is basically the ID, the Chitro head. And then we see another subscription instead for the feed 52 something. So we know that somebody has subscribed to people's feed instead. So intuitively, we know that they are both publishing and they're subscribed to each other, but it is not to be given for granted because you can actually use this plugin for things that are much more complex than that. And so we want to be sure of this. What we can do is basically looking at the events that were associated to the handle creation. And we see that these two different handles over here have the same opaque identifier. And so have these other two, which means that they both were originated by the same user basically. So we know that those handles were created by the same user. And looking at the session and handle identifier and things like these, we can basically reconstruct the topology which is that people is using a specific handle to publish. He's subscribed to a specific ID via different handle and so on. We know which handle belongs to whom. We can figure out that they are basically subscribed to each other, which is what we wanted to figure out. And this is basically how you can correlate information related to different plugins with each other, which is kind of cool. And just to conclude basically, because I managed somehow to talk about 95 slides in 15 minutes. So I deserve a prize for this. This is really something really new that we've been experimenting with. And the idea is that in the future, more and more plugins will come to basically handle these events in more creative ways. In the next presentation, Lorenzo will show us how they actually handle these to integrate these within the Homer framework. And it would be really nice to have actually a native plugin that acts as an event handler within Janus itself rather than relaying on a plugin that shoots events, an event to an OJS application, which then introduces the event in Janus, which could be quite cool. We will also have a student working on this kind of interaction in the future, which is kind of nice. But more importantly, I mean, help us play with these if you're interested in these. Just start using it. Let us know if there is anything more that is needed on this, or if you think it's actually just as nice as it is. And this is all I've got. So I'm open to questions if there is any time for that. We have like one minute left. Okay, that's good. Thank you very much. Thank you.