Call Detail Records Entry Loss - Revision history

Luc Morissette: Added title

2022-07-12T14:06:00Z

Added title

← Older revision		Revision as of 10:06, 12 July 2022
Line 1:		Line 1:
			{{DISPLAYTITLE:Incoherent CDR during switchover}}

	It is worth noting that some CDR records can be lost during transition from active to standby following a system fault. Consequently, a CDR analysis script must handle few "corner" cases:		It is worth noting that some CDR records can be lost during transition from active to standby following a system fault. Consequently, a CDR analysis script must handle few "corner" cases:

Abrassard: moved Text Call Detail Records Entry Loss to Call Detail Records Entry Loss: This page is "generic" to both Text and Radius

2012-10-19T20:16:13Z

moved Text Call Detail Records Entry Loss to Call Detail Records Entry Loss: This page is "generic" to both Text and Radius

← Older revision	Revision as of 16:16, 19 October 2012
(No difference)

Abrassard: Creating this page

2012-10-19T20:14:48Z

Creating this page

New page

It is worth noting that some CDR records can be lost during transition from active to standby following a system fault. Consequently, a CDR analysis script must handle few "corner" cases:

== A "Start" CDR entry without corresponding "End" entry ==
This happens if a call was terminated during the switchover period.

==> In that case, billing the call is not possible, the "End" CDR information was lost.

== A "End" CDR entry without corresponding "Start" entry ==
This happens if a call was answered just before the HA switchover occurred, and the CDR entry was not yet flushed to disk.

==> In that case, billing can still be done using the "End" entry's "end time" versus "connected time" (unless connected time is 0, meaning the call was never answered)

== A call with two "End" CDR entries ==
This case may happen after some partial HA switchover of the Toolpack system:
* The CDR generating application (Gateway) remains alive, but looses it's connection with toolpack_engine
* After a timeout, it destroys it's call contexts, and thus writes CDR "End" entries.
* Later, connection with toolpack_engine is re-established, and some calls were still valid and connected
* The Gateway application re-synchronizes with these calls. These call continue normally until they're hung-up
* When hung-up, another "End" CDR entry is written

==> In that case, billing can be done by using the "end time" of the second CDR entry, minus the "connected time" of the first CDR entry.