 Dan came here again and he's going to tell us what's new with CIGURATES. Yeah so thank you for organizing again all guys wonderful yeah so my name is Dan Bogos I'm part of CIGURATES project for who did not hear about us yet we are located in Berveria Germany over nine years of experience with both server side solutions in wholesale as well as retail and yeah we educate ourselves towards responsibly understanding the real-time processing constraints and what everybody or a lot of us experienced the seriousness of flight system outages. This is our background this is why how we came up towards CIGURATES we were designing large VoIP infrastructures and we needed reliable it's a pluggable solution so you can get it in your infrastructure it's able to accommodate new components it was designed to accommodate new components into ISP network for example add a new VoIP switch in your network an SMS service and put CIGURATES to help you billing that it's what what we focused on a lot it's non-introsive into existing setups so we should not participate into influencing your your switch or your switch crashes we just share information with your switch and it's the responsibility of the switch administrator to take decisions based based on that so the power we we transfer it to you we don't ask you to route your traffic towards specific like mammoth environment or or something it's it's all pluggable it's fully open source the full sources you can find on on github fork it modify it make it better we are happy to do that no add-ons so we don't put our business models towards selling add-ons in separate private we don't do that and there is a community behind ever-growing and you can get a hold of it over various channels we are performance oriented as a real-time solution we needed to be able to move a lot of traffic we we have focused a lot on building an advanced caching system that's actually the secret behind our performance this caching system it's it's transactional it it has a lot of this this are you the least used record it will be kicked out and hottest information will be always keep kept in memory we everything what we do it's asynchronous so it's towards non-blocking stuff and performance we use micro threads for that so we are not limited by the system threads and system thread limitations you can do theoretically millions of micro threads test-driven development as a rating engine this was the top priority for us it's we should be reliable so as as I speak we have about 1600 tests part of our test builds so this this works as our guard we are very we feel more secure by by doing this we have a modular architecture we did it cloud ready we have microservices you can as I told you we have various components which you can start stop make them talk to each other on the same server or spread over different even locations they all talk to each other between between themselves over RPC's this can be internal within process or between processes it's easy to enhance it by rewriting specific component you are not happy about our implementation you take for example our I don't know CDR server out you put your own and just keep our rating part and so on feature rich we we do various things we do a buzzword at some point multi-tenancy from day one we are a rating engine again the the original part of the system with derived charging and a number rating it starts being popular here around wholesale carriers to do a number rating account balances money management with bundles we do very complicated setups with bundles combining data SMS is this kind of playground of MVNO providers we do session management or event charging with balance reservation refunds again complicated things imagine that you need to refund out of a bonus and so on so it can in and also in real time it can become quite some fun to work with CDR logging which I will talk a bit about today with support also for interim records we have throw detection with automatic mitigation so you can leave the system while you flip to even shut down accounts for you if something does not look right you you can do various escalation procedures and so on if fraud is detected LCR module with QoS so it can take decision based on the the routes quality of your suppliers it can do also LCR over bundles which is not very common but useful you can get like thousand minutes which can be used for free in the weekend from a supplier of yours this this LCR is able to consider that call statistics with pattern monitoring and stuff like that calculate ASR a CD in real time and also react on it based on pattern diameter server useful again in MVNO scenarios in 3G 4G XG then resource allocation controller if you want to give your customers a number of channels or resources it's possible to see rates built in high availability so we can have maintain active active various components active passive and so on there are a lot of combinations you can do inside and we educate ourselves to be agile in developing new features a bit about history we started around 2012 and ever since we will keep pushing code this code would represent features for us because we are pretty conservative in adding a lot of code so our code we try to keep our code based as small as possible but it it was growing out of unplanned feature introduction implementation most of our actually all of our code is written in go we were quite pioneers pioneers in go in 2012 when we started with CG rates go is was in weekly release so it was quite interesting to grow CG rates and also go so we grew together I think and yeah we provide our own testing tools so you can you you can estimate how fast your system is based on your own data so you see a cgr tester within the same process we have estimated around 82,000 requests per second of in calculations and outside from a different programming language from Python for example via APIs we got almost 5,000 requests per second CDR server this is what the component responsible about CDRs it's accessible via a number of different APIs so you can push CDRs into CG rates via JSON HTTP HTTP REST GOP whatever there are a number of APIs already available to you you can also push over offline CDR CDR import so if you get the CDR from your suppliers over CSV XML fixed with value all these are supported it's automatic so I notify will tell us when you get the CDR into the folder and we automatically pick up so it's close to real time from the moment you you push it in you can we can monitor various folders there and have various import templates and logic per each folder so you get a lot of functionality also there what's important for the open source world we have plug-ins for a lot of open source solutions so we have for asterisk for example via ari we have free switch via fsock then we have kamaelio via evapi and we also have open seeds via the new module which opens sips core developers wrote it mode CG rates and of course regarding the the required thing by by mobile operator we have diameter support we have derive charging support these things are session emulation so if you get a lot of distributors and resellers in your network then you can use derive charging you get one CDR and fork it into unlimited so in this way you can get reseller or distributors chaining or inbound versus outbound traffic charging so you know how much you need to charge your customer and how much your supplier will charge you we have real-time CDR application and CDR exporter for CDRs which we store and the there is another useful components in regards to CDRs the CDR stats which is calculating stats in real time for you so you know as I told ASR ACD PDD and or average call cost for the queue the CDRs which are in our queues these queues are very performant they are in memory so you can get quite heavy traffic thrown on it and a lot of configuration parameters again and also you can it can be also a part of flow detection so you monitor the stats of your customers just a quick look on the on how you can process the CDRs via various interfaces we pass it over through internal components we can store it or not on our side and that's that's the the part I wanted to tell about performance this CDR replicator can pick the CDR from the moment we are done with rating which means few milliseconds after you have sent us the CDR and it can send it to you via a number of transports for example it can send via HTTP JSON or HTTP REST to you back and or put it in a in a queue the new module which would have just implemented so it's it's very useful because you can get your own database schema in this way you don't need to query any more cg rates and you stay fast because on all this path there is almost no disk involved so that that means very fast and from the moment you you send it to cg rates to the moment you get it already rated on your side it's few milliseconds so you get CDRs rated like from the cloud but with your own instance of rating so I think I did it so I have time for one question yeah what do you mean by time usage different price yeah we do that through using different account bundles or balances so you give 1,000 with a price and after 1,000 it's gone automatically you consume out of another one with different price yes please what do you mean by how do we keep our balances you mean in in float we keep but we round after each operation on it because we had some some issues with flow type but we came out that you know in go there is no stable solution yet for for decimals like in Python is so we we work with float but every after every operations we are rounding it we apply we apply rounding on it so in the end we get like others are using big numbers for it because sort of is the same solution but in a different way implemented in the next couple of months yes we are actively it's a it's an active project for us now after diameter it will be right radius thanks a lot thank you very much