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