[00:00.000 --> 00:10.600]  Okay, so hello everyone. My name is Dan. I'm from CG Race Project. Thank you for showing
[00:10.600 --> 00:18.080]  up. I will be pretty fast, so the rest, if you have any questions later, please, and
[00:18.080 --> 00:22.080]  if you don't understand something, the slides will be available later. So I'll do just
[00:22.080 --> 00:28.360]  digestive slides, whatever. So the company itself sitting behind the project, we are
[00:28.360 --> 00:35.840]  located in Germany and with some back offices in Romania and Albania, we did both wholesale
[00:35.840 --> 00:47.640]  as well as real-time retail business, sorry. So we understand by now what means a system
[00:47.640 --> 00:55.480]  outage. CG Race, it's a real-time enterprise billing suite. It's pluggable into existing,
[00:55.480 --> 01:00.640]  it's designed to be pluggable into existing infrastructures. You can accommodate easily
[01:00.640 --> 01:07.680]  new services and new ideas. So it's not only for telecommunication built. You can extend
[01:07.680 --> 01:15.520]  it like the new industries, IOT, electricity. We are going towards energy as well. So you
[01:15.520 --> 01:22.720]  can build anything you like. If you want to sell cars, you can just do it. And it should
[01:22.720 --> 01:28.200]  be non-intrusive into existing setups. So it should not make you change the way you
[01:28.200 --> 01:36.000]  are doing things. We are sharing information with your switch, your router, whatever infrastructure
[01:36.000 --> 01:44.320]  you are using over there. It's all open-source software. It was made in, born actually in
[01:44.320 --> 01:54.040]  2010 and we published first sources in 2012. The sources are available on GitHub. It's
[01:54.040 --> 02:03.360]  all 100% written in Go, one of the early adopters of Go. And we have nothing in private repositories.
[02:03.360 --> 02:11.720]  Of course, we appreciate community. It's performance-oriented, three branches, all three supported. Our customers,
[02:11.720 --> 02:23.160]  they tend to be like all telecommunication, a bit conservative with upgrading. So test-driven
[02:23.160 --> 02:32.520]  development, again, very sensitive to billing and data, and modular architecture. It's
[02:32.520 --> 02:37.400]  quite feature-rich. You can find all this information on the Internet, so I don't have
[02:37.400 --> 02:45.080]  to market it to you. This slide, it's complex a bit, but I wanted to show you because it
[02:45.080 --> 02:51.360]  relates to the subject of my talk, how to integrate with your existing infrastructure.
[02:51.360 --> 02:57.520]  So on the left side here, you see quite a number of agents which we support. These mostly
[02:57.520 --> 03:04.600]  are developed by us. They are also other agents like OpenSIP's module, which is built in their
[03:04.600 --> 03:12.800]  software. So you can build very easily and replace any of our agents. So what you will
[03:12.800 --> 03:18.680]  do in the end, you will send your API calls, because CGRATES is all about APIs. You will
[03:18.680 --> 03:25.760]  send directly to our session module, which you can also see it as central point of entry.
[03:25.760 --> 03:31.200]  After that, you will reach other modules of ours or subsystems, although they are also
[03:31.200 --> 03:37.720]  standalone API server on their own, but you will be using them through our sessions where
[03:37.720 --> 03:43.960]  we implement easier integration for your stuff.
[03:43.960 --> 03:50.360]  So how do you do that? First, you have to load the data. This is data-specific, so you
[03:50.360 --> 03:57.800]  have to follow our format into loading your rating, your accounting data in case of doing
[03:57.800 --> 04:06.800]  prepaid and postpaid. We have also some extra subsystems data, but you will be mostly focusing
[04:06.800 --> 04:12.960]  on rating and accounting. After you are done with building your data, then you have to
[04:12.960 --> 04:23.360]  understand how we support sessions. So you can choose all of these steps or only one,
[04:23.360 --> 04:28.560]  which is the last one and the most important session CDR. So you can do billing in real-time
[04:28.560 --> 04:38.040]  via sending us various messages, various APIs, or you can directly send us the NCDR for building
[04:38.040 --> 04:39.040]  it.
[04:39.040 --> 04:46.160]  So, for example, session authorization, you have the opportunity to extract from the billing
[04:46.160 --> 04:55.720]  engine, maximum session duration, resource authorization, various session properties,
[04:55.720 --> 05:02.360]  even password, you can retrieve it from the engine site, and you can also do session routing
[05:02.360 --> 05:08.200]  because we also support LCR on our site. Then sessions start when your sessions start, so
[05:08.200 --> 05:13.920]  you tell us start billing in real-time or start debiting in increments. You can choose
[05:13.920 --> 05:22.040]  the way, for example, the mobile networks, they are using session updates via diameter,
[05:22.040 --> 05:30.160]  so you can implement your own triggers for incremental debits. Or you can do like we
[05:30.160 --> 05:38.920]  are doing with open-source softwares, we support like FreeSwitch, Kamailio, OpenSips, send
[05:38.920 --> 05:44.840]  us session start and session stop, and we will do the magic behind. And then there will
[05:44.840 --> 05:50.120]  be the session CDR which can be standalone or can correct the session information from
[05:50.120 --> 05:54.120]  real-time, so both will work.
[05:54.120 --> 06:01.120]  And these are some examples of APIs, so if you want to implement in your own application
[06:01.120 --> 06:08.080]  like your own switching software or your own, I don't know, WebRTC application, all you
[06:08.080 --> 06:15.280]  have to do is send us this JSON RPC Blobs and we reply you, for example, this one is
[06:15.280 --> 06:20.920]  replying with the, we by the way use nanoseconds, you can also get back seconds if you want,
[06:20.920 --> 06:26.280]  but we want to be very verbose, so this one will just retrieve the maximum usage of a
[06:26.280 --> 06:32.720]  session. And the same with initiation, same you send us the information in your events,
[06:32.720 --> 06:41.680]  this is fully configurable, flexible, so you can add any number of fields inside.
[06:41.680 --> 06:49.440]  Same session update and terminate, and in the end the CDR sample and blob, same story,
[06:49.440 --> 06:53.360]  all API driven. So this was fast.
[06:53.360 --> 07:03.360]  Thank you.