 Don't go to f*** with it. Thank you for a good speech. At least it didn't go to the bathroom. Quick question here. How many of you know about OpenSips? Have heard about it and know what it is, at least. Cool. So to everyone else, OpenSips is a SIP proxy and leaving all the cool features aside, its main job after all is to route calls as many as possible. So today we're going to go through how the architecture has evolved in order for us to have the need for this event-driven approach. We're going to talk a bit about the events themselves and how they will open up new possibilities for future development and scenarios in SIP. Some concrete examples and maybe if there's some time left, look into some OpenSips script. Regarding the architecture, this is a mess but I'm going to explain it step by step. This is how most of the platform is running on OpenSips. Not most but people who are still using the 1.x series are using this kind of linear architecture where the horizontal lines are basically SIP message processing. That depending on how it's scripted on various platforms and services may either do more CPU intensive loads or more blocking type of loads with red. And of course we ideally want as less blocking as possible. So we felt the need, this was back in 2014 or something, to take it a step further and sort of deal with all this blocking IO which was eating up or reducing throughput so much. On these platforms where inevitably you have to run some sort of blocking queries, I don't know, database or HTTP and so forth. So the 2.x architecture, we treated this problem and we introduced asynchronous operations for the database level. You can basically throw the query and resume at some point in the future. And in all this time, as you can see, you can start doing more useful work. So the message processing is entirely dominated or mostly dominated by green now. So this is basically what the first releases in the 2 series that we're all about. And we eventually, we felt that even this is somewhat, it's not capable of solving all the issues with various scenarios. For example, the fact that one message may interact or may need to exchange data with some other message, totally unrelated, opens the need for a new mechanism. So with this in mind, we have the push notifications scenario which I'm going to go through in more detail in a short time. Also, some events from various external applications that OpenSIPS might interact with, such as the event socket layer of FreeSwitch or various VoIP scenarios, I should say SIP scenarios, which also require this process-to-process communication. So I'm going to try and keep things as generic as possible. Let's not go into too much SIP. So this is one way that this is the first type of scenario in this event-driven architecture which requires different processes to share data. So let's assume we have a SIP message that is being processed and at some point you have to block. You have to wait for the receivable of some other one, totally unrelated from a transaction point of view, that will unblock you. You will be able to resume processing only after that one is received. Of course this is the happy scenario where you actually receive the event, but you might also run into something like this. So nothing arrives. So somehow a timeout must be generated so you can take the appropriate action. I'm going to go back a bit and this is the exact scenario or way of information exchange that push notifications require. So if we map this initial request to an invite, we now have to wait for a register. I will detail this some more when we get into the scenarios. But as I said, let's just try to see the big picture for now. Another mode of operation of this event-driven architecture would be when we have a message as being processed, but the processing can be asynchronously interrupted in the same manner. So a message arrives that somehow affects this ongoing transaction. So again, the first process would have to register some handler that would run whenever the event is triggered. Let's talk about some concrete examples again. We may have, so again in the push notification scenario, we may have the need to fork. So when the call is received, we may fork to all the current desktop devices of a user. That's good. But we may also launch in the background these push notifications that may or may not add additional calls. So as soon as his mobile devices start registering, all of a sudden they are receiving the calls. Of course, this assumed that he hasn't yet answered the desk phone, right, because that would just set up the call. Another scenario that is possible with this approach would be call pickups. And this would be, it's a very elegant solution to call pickup. So the call pickup would work. The call, again, we receive the invite. And asynchronously, the pickup group would or would not generate an invite that would take over the call. So in this case, we'd have an invite waiting for a separate invite. So I'm going to now go into the event mechanism and look into, let's look into a bit more detail on how they work and how we structure them. So the events are triggered by some sort of, let's not just call the messages that OpenSIBs receives, but rather some point in execution, such as when a user is saved in the location or any sort of action like this. And they will basically hold enough information, sort of like these key value attributes, so we can properly match them and block until the exact event that we're looking for is received. Moving forward to the subscription mechanism. The interested processes, the OpenSIBs workers may subscribe to these events. And again, they may use the attributes I mentioned earlier to filter them so they can receive the appropriate response. And the response are these notifications, which will be dispatched to whatever to the subscribers I mentioned earlier. And it all works as a PubSub model. It's pretty straightforward. So now that the theory is away, we can go into some concrete examples and the long awaited push notifications discussion. So for those of you who, I'm sure most of you know what this is all about, but for those of you who don't, I'm going to quickly go through how these work and what limits. So what the purpose is. So when a call is received, if a user is not found, a mobile device user, we can throw this push notification to get it to register and ultimately receive the call. And the main usefulness of this is to save some, save battery on these mobile devices because you cannot have them constantly registering to the platform because they would be drained pretty much pretty fast. So SIP is quite expensive from this point of view. So with this in mind, the funny thing is that once we made the async and we turned as many blocking operations into their async counterparts as possible, we actually made it possible to implement push notifications already in the 2.2 branch. But this is a bit deceiving and I'm going to talk a bit about how they work now. So this was one of those scenarios you don't even, you don't consider, right? Because you're here in time and it's, you'd have to be a genius to just foresee everything. So you do it like this, call arrives, we send the push notification and then we do this sort of feedback loop where we asynchronously sleep and just do this poll. If he's registered, sleep, if he's not registered yet, sleep some more. So, yeah, this is sort of a, you know, hackish way to do it, but it apparently works. So what are the problems with this approach? So, first of all, it's a performance killer because if we go back a bit, we can, it's a trade-off between user responsiveness and how much we want to spend in terms of CPU. So also, it's inflexible. It cannot handle scenarios where we'd want to successively ring multiple mobile devices of that user. We can only do it once. Also, the same idea applies to failover, to multiple gateways. We only are able to do it once. So all of these issues are solved with the event-driven paradigm because now, once the call arrives, we simply subscribe for this event, register event. Of course, we parametrize it a bit with Bob AOR and we install this handler. But also, we can, of course, we launch the push notification and we fork the phone to the devices that are currently registered. And should the push notification actually work, we simply add some more branches. Add the appropriate branches and do it as many times as needed. Another possible application would be to, would be that it opens the door to automatically detect robots on the other side. So, I mean, fax machines or voicemail. So with this in mind, we would subscribe to a DTMF event linked to a certain call ID and simply forward the call. If the media server, so when the media server starts sending the events, we will take the appropriate actions. We will invoke the handler and hang up if it timed out or if he, I don't know, pressed the wrong digit, I guess. So also jumping into some open-sip script, things would kind of look like this. We subscribe to the AOR, we send, I guess it's on this slide. This is how the push notification code would look like. And so let's go through it a bit. We open some headers and make a post using the REST client module. And then I went back and now we will fork to his existing branches and hold the execution. I think, yeah, I've also added the handler. Once the events start arriving, so the registrations, we can do the appropriate checks based on, because this is again another kind of worms, the whole detecting of unique contacts and so on and so forth. But we basically relay only when it's needed. So to draw some conclusions, this new paradigm is very powerful. It's going to make script usage a lot easier, because if we go back a bit to the async method, that really kind of produces a lot of ugly code. So that's going to be another boost. And it opens the doors to all these complex scenarios that you solve within just a couple of lines of code. And it's also going to, it's quite extendable, so we can define as many events as we want. A couple of words about the whole release, that's due to some sort of mid-March. This is just the tip of the iceberg, the event-driven approach, because the release is codenamed integration. And it incorporates a lot of integrations with various projects that are vital to any critical VoIP application or system, such as capturing SIP packets, handling billing, media server, and maybe adding some middleware, RabbitMQ. So as a takeaway message, keep in mind that there is still room for some tweaking, so please give us a shout out on the mailing lists or IRC. And if you feel like you could improve on the design, by the way, all of these will be available shortly online, so we can maintain this feedback loop on the event-driven approach. So thank you. And if you have any questions, sure. What kind of support is needed by the endpoints? I mean, you're speaking about sending a question request, so the device, the question endpoints, register so it can receive the invite. Yes. That means your endpoints need to be intelligent enough to handle this thing, a plain old basic SIP phone or maybe just a regular mobile phone. You don't know how to deal with this. Do you need a dedicated SIP client on your phone, for example, to take advantage of this infrastructure? Definitely, because we're talking about mobile and desk phones may register as often as they want. In fact, the problem is that mobile devices need to register often, right? So they have these short registration times, and this is why the push notifications and, as you said... So you're talking about the dedicated SIP client? Yes, of course. It's all about the app. It has to handle these. It needs to wake up, right? The push notification results in a wake-up of the VoIP app. So it registers and receives the call. A couple more minutes. Sure. How many of these dedicated VoIP apps exist already but know how to deal with these push notifications? I wouldn't... I would only say that Zuiper. So basically, yeah, I guess the question we should turn it backwards. Are there any apps that do not wake up and register, right, when they receive a push notification? Are there any apps that don't register? I don't think so. The thing is, because iOS and Android will cut your connections, especially iOS. There is no phone running around. There used to be one, not anymore. So now, if you want your VoIP app to basically be responsive when it's in the background, and when you're in the background, it will cut your TCP connections. So you're dead. You cannot do anything. You do have, like, three minutes of runtime, I think, when you go to background to set up stuff. So you're like, okay, let me know when I have a call. And then you need to set up... It's not like enabling push notifications. You need to have, like, your back end needs to keep track of the device IDs and when you get the call, send it to the right device. So it's not like...