uppal/cgrates
1
0
Fork 1
mirror of https://github.com/cgrates/cgrates.git synced 2026-02-11 18:16:24 +05:00
Code Issues Packages Projects Releases Wiki Activity

Docs - another index reformat

Browse Source
This commit is contained in:
DanB
2020-01-19 13:30:35 +01:00
parent f03b402aff
commit 3ac85fd023
2 changed files with 56 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
docs/index.rst
View File

@@ -13,70 +13,21 @@
.. _OpenSIPS: https://opensips.org/
Introduction
============
Preface
=======
Welcome to `CGRateS`_'s documentation!
`CGRateS`_ is a *very fast* (**50k+ CPS**) and *easily scalable* (**load-balancer** + **replication** included) **Real-time Enterprise Billing Suite** targeted especially for ISPs and Telecom Operators (but not only).
Starting as a pure **billing engine**, CGRateS has evolved over the years into a reliable **real-time charging framework**, able to accommodate various business cases in a *generic way*.
Being an *"engine style"* the project focuses on providing best ratio between **functionality** (over 15 daemons/services implemented with a rich number of `features <cgrates_features>`_ and a development team agile in developing new ones) and **performance** (dedicated benchmark tool, asynchronous request processing, own transactional cache component), however not losing focus of **quality** (test driven development policy).
It is written in `Go`_ programming language and accessible from any programming language via JSON RPC.
The code is well documented (**go doc** compliant `API docs`_) and heavily tested (**5k+** tests are part of the unit test suite).
Meant to be pluggable into existing billing infrastructure and as non-intrusive as possible,
CGRateS passes the decisions about logic flow to system administrators and incorporates as less as possible business logic.
Modular and flexible, CGRateS provides APIs over a variety of simultaneously accessible communication interfaces:
- **In-process** : optimal when there is no need to split services over different processes
- **JSON over TCP** : most preferred due to its simplicity and readability
- **JSON over HTTP** : popular due to fast interoperability development
- **JSON over Websockets** : useful where 2 ways interaction over same TCP socket is required
- **GOB over TCP** : slightly faster than JSON one but only accessible for the moment out of Go (`<https://golang.org/>`_).
CGRateS is capable of four charging modes:
- \*prepaid
- Session events monitored in real-time
- Session authorization via events with security call timer
- Real-time balance updates with configurable debit interval
- Support for simultaneous sessions out of the same account
- Real-time fraud detection with automatic mitigation
- *Advantage*: real-time overview of the costs and fast detection in case of fraud, concurrent account sessions supported
- *Disadvantage*: more CPU intensive.
- \*pseudoprepaid
- Session authorization via events
- Charging done at the end of the session out of CDR received
- *Advantage*: less CPU intensive due to less events processed
- *Disadvantage*: as balance updates happen only at the end of the session there can be costs discrepancy in case of multiple sessions out of same account (including going on negative balance).
- \*postpaid
- Charging done at the end of the session out of CDR received without session authorization
- Useful when no authorization is necessary (trusted accounts) and no real-time event interaction is present (balance is updated only when CDR is present).
- \*rated
- Special charging mode where there is no accounting interaction (no balances are used) but the primary interest is attaching costs to CDRs.
- Specific mode for Wholesale business processing high-throughput CDRs
- Least CPU usage out of the four modes (fastest charging).
More overview content:
.. toctree::
:maxdepth: 1
overview.rst
Table of Contents
-----------------
Table of contents:
.. toctree::
:maxdepth: 5
overview
architecture
installation
configuration

54
docs/overview.rst
View File

@@ -1,8 +1,56 @@
.. _cgrates_features:
Features
Overview
========
Starting as a pure **billing engine**, CGRateS has evolved over the years into a reliable **real-time charging framework**, able to accommodate various business cases in a *generic way*.
Being an *"engine style"* the project focuses on providing best ratio between **functionality** (over 15 daemons/services implemented with a rich number of `features <cgrates_features>`_ and a development team agile in developing new ones) and **performance** (dedicated benchmark tool, asynchronous request processing, own transactional cache component), however not losing focus of **quality** (test driven development policy).
It is written in `Go`_ programming language and accessible from any programming language via JSON RPC.
The code is well documented (**go doc** compliant `API docs`_) and heavily tested (**5k+** tests are part of the unit test suite).
Meant to be pluggable into existing billing infrastructure and as non-intrusive as possible,
CGRateS passes the decisions about logic flow to system administrators and incorporates as less as possible business logic.
Modular and flexible, CGRateS provides APIs over a variety of simultaneously accessible communication interfaces:
- **In-process** : optimal when there is no need to split services over different processes
- **JSON over TCP** : most preferred due to its simplicity and readability
- **JSON over HTTP** : popular due to fast interoperability development
- **JSON over Websockets** : useful where 2 ways interaction over same TCP socket is required
- **GOB over TCP** : slightly faster than JSON one but only accessible for the moment out of Go (`<https://golang.org/>`_).
CGRateS is capable of four charging modes:
- \*prepaid
- Session events monitored in real-time
- Session authorization via events with security call timer
- Real-time balance updates with configurable debit interval
- Support for simultaneous sessions out of the same account
- Real-time fraud detection with automatic mitigation
- *Advantage*: real-time overview of the costs and fast detection in case of fraud, concurrent account sessions supported
- *Disadvantage*: more CPU intensive.
- \*pseudoprepaid
- Session authorization via events
- Charging done at the end of the session out of CDR received
- *Advantage*: less CPU intensive due to less events processed
- *Disadvantage*: as balance updates happen only at the end of the session there can be costs discrepancy in case of multiple sessions out of same account (including going on negative balance).
- \*postpaid
- Charging done at the end of the session out of CDR received without session authorization
- Useful when no authorization is necessary (trusted accounts) and no real-time event interaction is present (balance is updated only when CDR is present).
- \*rated
- Special charging mode where there is no accounting interaction (no balances are used) but the primary interest is attaching costs to CDRs.
- Specific mode for Wholesale business processing high-throughput CDRs
- Least CPU usage out of the four modes (fastest charging).
Features
--------
- Performance oriented. To get an idea about speed, we have benchmarked 50000+ req/sec on comodity hardware without any tweaks in the kernel
- Using most modern programming concepts like multiprocessor support, asynchronous code execution within microthreads, channel based locking
- Built-in data caching system with LRU and TTL support
@@ -113,7 +161,7 @@ Features
Links
=====
-----
- CGRateS home page `<http://www.cgrates.org>`_
- Documentation `<http://cgrates.readthedocs.io>`_
@@ -125,6 +173,6 @@ Links
License
=======
-------
`CGRateS`_ is released under the terms of the `[GNU GENERAL PUBLIC LICENSE Version 3] <http://www.gnu.org/licenses/gpl-3.0.en.html>`_. See **LICENSE.txt** file for details.