 We have Dan Christian Bogos using CGR8. Thank you. Okay. So, hello everybody. Thank you for surviving until this time. It's amazing. So, I'm here to talk about CGR8 today. And yeah, I'm part of the project since a while now. And we got quite some new additions and exciting functionality over the time. And yeah, a bit how we reached here just to understand why we came to CGR8. So, we are a company in Germany. Since over 10 years, we were doing server-side solutions in VoIP environment. We had both retail as well as wholesale projects. And in time, we needed to have a proper way of rating. So, during this time, we also considered that we were educated in the hard way around the life system outages. This is how CGR8 came up. So, CGR8, it's some mixture of terms. It's something which works real-time. It's coming close to billing, although it's only a billing engine. And it's a suite of things because it has more component than just a billing engine. It's enterprise because it's customizable, so you can use it as a framework to do your own thing. So, you can customize it to help you solving your billing issues. It's all open source. So, full sources are available on GitHub. We don't have any add-ons in private repositories, and we really respect and consider the tips from our community. It's a non-intrusive, by the way, it's a non-intrusive billing system, so it will not force you routing your calls through us or do other tricks in order to get the billing out. It simply communicates in real-time with your communication switch or other routing service. It's designed around performance, being online and real-time. It needs to be fast. For that, we have used or we have developed our own caching server and system inside, which is transactional. It has support for LRU, if you know least record used, and it also has support to time out the items in cache. Everything what we do, it's asynchronous, so we use this microtreads, which everybody, all the Go developers know by now that they are very powerful and handy. Talking about Go, by the way, I think we are one of the oldest projects around. We started sometimes in 2010, so by that time Go was in weekly release stage, so we took quite some risk starting a billing engine in unknown programming language, which was kind of fine as well. It's a test-driven development project. Today we have more than 4,000 tests which we run on our builds. We have both unit tests, integration tests, also call simulation tests, so it's something which protects us quite seriously from making or hitting ourselves. It has a modular architecture. It's cloud-ready, so it's based on microservices. Everything what CDurace does, it does it through APIs. We call it even when CDurace breathes, it does it through an API. It's easy also to enhance it by replacing specific components, so you can simply, you don't like something which we wrote. You take it out, you put your own component, and the rest of them should be working like it was working before. It's feature-rich, so we are what others are calling online or offline charging system. It's multi-tenant. We have the oldest component as a rating engine with derived charging. This derived charging gives you a possibility to fork CDRs or calls, so you can in parallel build all of your distributors, all of your suppliers, and your customer. So it helps you solving some issues as well there. We have account balances. This bundles what others are calling. You can have unlimited bundles. So you have data bundles, minute bundles, monetary. You can play with them like queuing the order they are processed. You can fail over and so on between them. And we do session or event charging with balanced reservation and refunds. So this is also something you need if you are doing online charging. We have plugins or what we call agents to major open source VoIP systems. CDR logging. So we also are able to, we have a CDR server, so you can send us the CDRs. We support also interim records, and we also support online exports. This online exports gives you the possibility to have the CDRs rated in real time and posted to your own infrastructure. So you don't need to use our server. So you get something what we call rating queues. So you push one CDR to us and few milliseconds later you get it on your side already rated. It emulates like you are receiving from the switch the CDRs already rated. So this helps you not changing your existing billing infrastructure. Regarding the another important chapter, we do fraud detection with automatic mitigation. So we have some modules flexible in doing that. We support LCR computation and some particular cases. So LCR based on quality. So you can select your suppliers based on how good they terminate your calls. And you also, we also have LCR over bundles. So if they offer you some free minutes over weekend or something you can, or the system can bring them into service just for the duration of the bundles. We have a statistics service. So it's able to compute generically statistics for you. It's all online. So you can have in a matter of milliseconds, ASR, ACD for your customer for the last one hour, last one day, whatever you put in your filters. So this is also useful to help you monitoring and react on traffic pattern changes or something. You can set some triggers. So your customer or your supplier gets notified when ASR drops. So it can help you on this. And then we have what we will discuss, diameter or radio server implementation with some process templates making the whole thing protocol or standard agnostic. It's important because at least in the diameter world everybody has its own extensions and it's quite hard to be compatible with all the vendors around. We have also built in high availability support. So we know how to failover between various components and connection failure. And we also educate ourselves to be agile in developing new features. So you have a new feature. We want to hear about it and please put it on our github. Just to understand the project you can see some of its history. One of the first commits is from before 2012 and ever since our code based race. So we were constantly adding features during this time and constantly developing the project. To understand how CG rates works I have put the components which are part of the CG rates ecosystem. This is also the reason why I told you it's like a framework because you have many components which are working together and each with isolated functionality. Each of these components can be a standalone server or service or they can all be integrated into one process. They can talk between them at process level via some, if you know, go via channels. So for them it doesn't matter whether they talk internally over channels or they talk externally over RPC. They don't know about that. So in this way you can scale on demand. When you get a scalability problem you just throw in some new hardware and split a component there. So part of the components or some of the components are like attributes. This attribute is like an alias server or user profile server. So if things are missing from your request you are able to add them through these attributes. RALS is the component where we do the rating and accounting. So there is where cost is showing up and also accounts are managed. STATS is the statistics service. It's a generic one so you can implement new algorithms or new methods of computation by simply adding some function. Resources are able to compute the resources used by your customers so you can offer them, I don't know, channels for a specific destination or count their request per second. So this is what resource helps you for. And then thresholds is to do fraud management or notifications. So you can monitor your traffic. And you can see all the agents which we have. So each of these agents will work as a protocol converter. You have diameter, you have radius, then an asterisk agent for asterisk over ARI. So FreeSwitch is also supported, Kamailio, and also there is a module within OpenSIPs, ModCG rates doing exactly the same thing and a general session manager dealing with sessions. We also have support for importing generic CDRs. So you can throw in any CSV or XML and you can configure templates to process it. Regarding diameter and radius agents, we have, as I told you, a generic protocol converter. It's protocol agnostic and you can define all its logic in JSON processing templates. You can have multiple matching processors at the same time. You can have fallback in between them. You can debug your templates. And you can also do processor variable overloading between the process. We have, when it comes to radius, you can also define a bit more advanced. You can have per client secrets or dictionaries. We did that in our own library. So we are also encouraging you to use that. We maintain a radigo as radius library in Go. Some idea to have on how you define the templates. So you will, for example, in case of diameter, you will select the CCR fields which you want to convert and send it to CG rates. And you also will select which fields you want in the diameter answer. So in CCA answer being sent back to diameter client. Out of the diameter event, you will have internal event going to CG rates. So you see here the event which is produced out of a complex, complicated event in diameter. And you can see as reply, you have more modules based on what you have selected to be requested in the request. You get specific answers and you see here attributes like querying the database or resources for monitoring resources. You have the maximum usage of your call. This is the value in nanoseconds because this is how Go defines time duration. And then you have the list of suppliers if you are interested with their cost and why they were selected. Again, it's all integrated in one API call. So I went fast. I don't know. Do I still have time for questions? Okay. So if any question, I know I was a bit fast. Not seriously. We use it in production since one-half years. We have this particular customer sometimes speaking 500 requests per second with 50,000 active sessions. So it's quite stable for us. Oh, nice to meet you. So it's really a good library. So nice to meet you again. There are some benchmarks because there is some caching but the numbers are always different. Yeah. It depends. Sorry. He's asking me if I have some benchmarks on caching. So I told you in production benchmarks were like around 500 requests per second with 50,000 simultaneous sessions up. We are working. We didn't have a customer more than 500 because they have like 600,000 prepaid users. So this is quite a large network. But if you want to go above that, we are working on a balancer solution which should be available in maximum two, three months, I think. Or let's say five months. As soon as you have the network, if you have today the network, I would be more than happy to assist it to bring it up. But there was nobody that high. So thank you. Yeah. This is what I heard also. Thank you. Thank you very much.