Page suivante Page précédente Table des matières

8. Accounting Configuration

The following sections in the config file can be used to configure accounting.

8.1 Section [Gatekeeper::Acct]

The section defines a list of modules that will be performing accounting. The accounting is for logging gatekeeper on/off events and call start/stop/update events. Each accounting module logs received events to a module specific storage. Such storage can be a plain text file or a RADIUS server and many more. The configuration is very similar to the one for gatekeeper authentication (see [Gatekeeper::Auth]).

All CDRs are also sent to the status port and can be used by external applications.

Syntax:

acctmod=actions

 <acctmod> := FileAcct | RadAcct | SQLAcct | ...
 <actions> := <control>[;<event>,<event>,...]
 <control> := optional | required | sufficient | alternative
 <event>   := start | stop | connect | update | on | off
The event list tells the gatekeeper, which events should trigger logging with the given accounting module (if an event type is supported by the module): An event logging by a module may results in one of the three result codes: ok, fail, next. Accounting modules can be stacked to log events by multiple modules or to create failover setups. control flag for each module, along with result codes, define what is the final status of the event processing by the whole module stack. If the final result is failure, some special actions may take place. Currently, if a call start event logging fails, the call is disconnected immediatelly. The following control flags are recognized:

Currently supported accounting modules:

The sample configuration #1 (try to log call start/stop with RADIUS server, and always write a CDR to a text file):

Example:

RadAcct=optional;start,stop
FileAcct=required

The sample configuration #2 (try to log call start/stop with RADIUS server, if it fails use a CDR log file):

Example:

RadAcct=alternative;start,stop
FileAcct=sufficient;stop
default=accept

The default rule is required here to prevent calls from being rejected because of RadAcct start event logging failure. If RadAcct returns fail return code, it is passed down to FileAcct module. FileAcct module does not support start events, so it returns next return code. If there were no the default rule, the final status would be failure, because no module has been able to log the event.

The sample configuration #3 (always log call start and stop events with RADIUS server, if it fails for call stop event, use a CDR file to store call info):

Example:

RadAcct=alternative;start,stop
FileAcct=sufficient;stop
default=fail;start

The default rule is optional here. If RadAcct returns fail return code for start event, the code is passed down to FileAcct module. FileAcct module does not support start events, so it returns next return code. The default rule ensures, that the call is disconnected if call start event could not has been logged with RadAcct. But we want to store a CDR in a text file in case the RADIUS server is down when the call disconnects, so we can fetch call duration into a billing system later.

8.2 Section [FileAcct]

This accounting module writes CDR lines to a specified text file. The CDR format can be a standard one (the same as displayed by the status interface) or a customized one (using parametrized query string).

8.3 Section [RadAcct]

This accounting module sends accounting data to a RADIUS server. Module configuration is almost the same as for RADIUS authenticators (see [RadAuth] and [RadAliasAuth] for more details on the parameters).

8.4 Section [SQLAcct]

This accounting module stores accounting information directly to an SQL database. Many configuration settings are common with other SQL modules.


Page suivante Page précédente Table des matières