CDR redundancy - Revision history

Allyntree at 17:49, 1 September 2020

2020-09-01T17:49:54Z

Nicole Tan: NT: Added Radius Accounting and Authentication Redundancy link for rel2.7

2014-02-04T20:12:00Z

NT: Added Radius Accounting and Authentication Redundancy link for rel2.7

Luc Morissette: New page for CDR redundancy

2012-07-09T20:19:10Z

New page for CDR redundancy

New page

'''''Applies to version(s): v2.6'''''
{{DISPLAYTITLE:Toolpack: CDR Redundancy}}

With version 2.6, the CDR processing has improved substantially, including various methods to protect against loss of CDR records. Here is a detailed explanation of the functionalities.

== CDR Redundancy ==

=== Radius redundancy ===
More than one radius server can be configured. When a server starts responding, the RADIUS client will flag this server as 'online'. When a server is flagged as 'online' and there are no other 'online' servers at that time, the server is elected as 'current' (primary).
All new CDR records will be sent to the primary, until it no longer responds. This list of Radius servers can be configured here: [[Toolpack:Configuring RADIUS B|Configuring Radius]]

=== Radius and Text CDR ===
This will send records to the Radius servers list and will also store it in [[Text Call Detail Records (CDR)|Text CDR]].

=== Text CDR fallback ===
This functions will only be used if there are no Radius servers 'online', or if the records queue is full. Otherwise, it works the same way as [[Text Call Detail Records (CDR)|Text CDR]].

=== Text CDR on Redundant servers (CDRs on both servers) ===
If you are using a TMG7800, both servers can log Text CDRs locally.
Text CDRs are not copied between hosts, therefore it is necessary to gather the CDRs from both hosts.

== How does it work? ==
There are two cases where the RADIUS client will consider that a CDR record couldn't be sent:

=== Request timeout ===
When a CDR record is received by the RADIUS client and the number of concurrent records is not reached, it is assigned
to the server which is considered 'current' (primary) at the time. It might be a server that is currently offline. A
request is first sent. If it times out (according to the configured timeout for that server), the request is sent again
(up to the number of configured Retransmissions). If all the retries timed out, the server is flagged as 'offline', a new
'current' (primary) server is elected and the record is discarded (that is reflected in the "Acct unanswered record cnt"
status item) [Add link].

=== Record queue full ===
When the number of records reach the "maximum accounting queued records" (default 12,000) the records will be discarded.
This is shown in the "Acct overflow record cnt" status item [Add link]

=== Text CDR Fallback ===
In both cases, if text CDR fallback is configured, it will be forwarded to the text CDR module. Otherwise, the record is lost forever.
There is no exception to that procedure. Even if all RADIUS servers are considered offline at some point, all CDR records will still be sent to all RADIUS servers, regardless if text CDR fallback is enabled.

← Older revision		Revision as of 17:49, 1 September 2020
Line 1:		Line 1:
−	~~'''''Applies to version(s): v2.6'''''~~	+
	{{DISPLAYTITLE:Toolpack: CDR Redundancy}}		{{DISPLAYTITLE:Toolpack: CDR Redundancy}}

@@ Line 9: / Line 9: @@
 More than one radius server can be configured. When a server starts responding, the RADIUS client will flag this server as 'online'. When a server is flagged as 'online' and there are no other 'online' servers at that time, the server is elected as 'current' (primary).
 All new CDR records will be sent to the primary, until it no longer responds. This list of Radius servers can be configured here: [[Toolpack:Configuring RADIUS B|Configuring Radius]]
 === Radius and Text CDR ===