This section documents the storage requirements for AVP CDRs.
Binary CDR log structure
Each CDR log file can be broken down into the following parts:
-
Protobuf overhead - a small amount of type information about contained records.
-
A header section - a small amount of data written by the CDR RA including version, host, and timestamp information.
-
Zero or more AVP CDRs - these records will vary in individual size, and usually form the majority of a CDR log.
-
A footer - this is empty for Sentinel products.
Sizing analysis
The combined size of the header, footer, and protobuf overhead is normally trivial (<1KB) compared to the size of each finished CDR log file.
Individual CDR records will vary in size based on dynamic content such as hostnames, Sentinel selection key names, SDP content, and other similarly variable character data. As such, it is not possible to provide exact sizing for a given system without examining the CDR logs written while under a test load, but some approximations can be made.
A basic CDR record containing the information normally written by Sentinel will be on the order of 2000-3000 bytes. With this in mind, the following sections provide rough estimates regarding how much storage would be required for specific scenarios.
If Sentinel is configured to write Session CDRs (i.e. not writing Interim CDRs), then each session will write a single CDR on the order of 2000-3000 bytes.
This section documents the storage requirements for the AVP CDRs written by the CDR RA when Sentinel VoLTE is configured to output Interim CDRs.
B2BUA CDR Sizing
This scenario involves writing CDRs for a single leg of a two party call.
Assuming a Start and End CDR are always written for the call, and assuming an average CDR size of 2500 bytes, each call will require a minimum of 5000 bytes. In addition, the Interim CDR feature can be configured to write CDRs periodically as a call progresses, or in response to SDP changes. Each of these events will produce additional records.
Taking these additional timer driven and SDP driven records into account, a rough approximation of the CDR storage requirements can be made with a formula such as:
2500 * Sessions Per Second * (2 + (Average SDP Driven CDRs Per Session) + (Average Timer Driven Interim CDRs Per Session))
It isn’t possible to use average call length when calculating storage requirements for timer driven CDRs as the number of timer driven CDRs written per call is sensitive to actual rather than average call length.
With the guideline above, we can perform approximations based on an example scenario:
-
No SDP changes outside of initial call setup.
-
95% of calls last under the default Interim CDR timer threshold (5 minutes by default).
-
5% of calls last for 59 minutes and trigger numerous timer driven Interim CDRs during that period. With a 5 minute interim CDR timer, this will mean 11 timer driven interim CDRs.
-
The overall system is running at 100 session per second.
Using the above, we can assume that the average number of interim timer CDRs per call is 0.05 * 11, or 0.55 per session. This results in an estimated storage requirement per second of:
2500 * 100 * (2 + 0 + 0.55) = 637500 bytes / second
or 2189MB / hour
Additional considerations for MMTel B2BUAs
MMTel is invoked for originating and terminating triggers, and therefore for each call one originating session and one terminating session.
Therefore MMTel typically uses 2x the storage requirements of a single B2BUA.
It is often the case that terminating calls are not charged unless the served user is roaming; therefore the default configuration for MMTel suppresses writing of SDP CDRs for terminating calls if the served user is not roaming. This is supported through use of the SuppressSdpCdr feature.
MMTel Conference CDR sizing
A conference call involves a long lived moderator leg, and one or more short lived consultation legs used to bring an additional users into the conference. A three-party conference call flow is available for reference.
The moderator’s conference leg will write 2 CDRs (start and end) plus additional SDP and timer driven CDRs. The short-lived consultation legs will usually only write 2 CDRs as they are just used to bring additional participants into the conference.
This means that for a three party conference, there will be a minimum of 6 CDRs written, plus any SDP and timer driven CDRs for the moderator leg.
A rough approximation of the CDR storage requirements can be made with a formula such as:
2500 * Conferences Per Second * ((2 + Average SDP driven CDRs Per Moderator Leg + Average Timer Driven Interim CDRs Per Moderator Leg) + (2 * Average number of participants))
Using the guideline above, if we assume the following scenario:
-
No SDP changes outside of initial call setup.
-
Each conference has 5 participants.
-
Each conference lasts 59 minutes (triggering 11 timer-driven Interim CDRs).
-
System is running at 5 conferences per second.
Then we can assume that the CDR storage requirements will be:
2500 * 5 * ((2 + 0 + 11) + (2 * 5)) = 287500 bytes / second
or 987MB / hour
