VOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction Critical

VOS3000 CDR Pipe Format Definitive 18-Field Important Reference Guide

VOS3000 CDR Pipe Format Definitive 18-Field Reference Guide

๐Ÿ“Š Every VOS3000 operator who exports call detail records must understand the VOS3000 CDR pipe format down to the individual field level. The pipe-delimited text file is the universal interface between your softswitch and every external system that consumes call data โ€” billing platforms, fraud detection engines, analytics dashboards, and regulatory compliance archives. A single misinterpreted field can cascade into billing errors, incorrect traffic reports, or failed audits. Yet the official manual provides only a brief field listing, leaving operators to figure out data types, edge cases, and integration mappings on their own. ๐Ÿ”

โš™๏ธ This guide provides a definitive, field-by-field reference of every column in the VOS3000 CDR pipe format. Each field is documented with its position in the pipe-delimited line, data type, example value, special considerations, and how it maps to external billing and analytics systems. All field definitions are sourced from the official VOS3000 2.1.8.0/2.1.9.07 English manual ยง4.4 (pages 241โ€“243), with additional practical guidance based on real-world parsing and integration experience. ๐Ÿ“˜

๐ŸŽฏ Whether you are building a Python CDR parser, configuring a MySQL import pipeline, or integrating VOS3000 with a third-party billing system, this reference eliminates the guesswork from field mapping and data interpretation. Let us walk through every field in the exact order it appears in each CDR line. ๐Ÿ”ง

Table of Contents

๐Ÿ” VOS3000 CDR Pipe Format Overview

๐Ÿ“ When SS_CDR_RECORD_TO_FILE is enabled in VOS3000, the softswitch generates hourly text files in the cdr/ directory. Each file follows the naming convention YYYYMMDDHH.txt, and each line within the file represents one call detail record with fields separated by the pipe character (|, ASCII 124). The format specification is documented in the official VOS3000 manual ยง4.4.

๐Ÿ“‹ CDR Line Format Structure – VOS3000 CDR Pipe

callerE164|calleeE164|startTime|stopTime|holdTime|endReason|
endDirection|callerGatewayId|calleeGatewayId|callerIp|calleeIp|
callerAccessE164|calleeAccessE164|callerToGatewayE164|
calleeToGatewayE164|calleeBilling|billingMode|callerPdd|calleePdd

๐Ÿ“ Field count note: The VOS3000 manual ยง4.4 documents the header line with 18 pipe separators producing 19 columns. The first 17 fields (through billingMode) are the core billing-critical fields present in all CDR records. Fields 18 and 19 (callerPdd and calleePdd) provide Post-Dial Delay metrics that measure call setup timing. Your parsing logic should handle both 17-field and 19-field records for maximum compatibility across VOS3000 versions.

๐Ÿ“Š Complete Field-by-Field Reference – VOS3000 CDR Pipe

๐Ÿ“‹ Below is the definitive reference for every field in the VOS3000 CDR pipe format, in the exact order they appear in each line:

Field 1: callerE164 โ€” The Caller ID ๐Ÿ””

AttributeValue
๐Ÿ“Œ Field Position1 (first field)
๐Ÿ“ Data TypeString (numeric E.164 format)
๐Ÿ“ DescriptionThe caller ID โ€” the originating party’s phone number
๐Ÿ”ข Example12125551234
โš ๏ธ NotesMay differ from callerAccessE164 after prefix transformations

๐Ÿ’ก Practical note: The callerE164 field reflects the caller ID after VOS3000 has applied any configured prefix transformations. This is the number as seen by the billing engine, not necessarily the original incoming number. For the original incoming caller ID before any transformations, refer to Field 12 (callerAccessE164). Understanding this distinction is essential when troubleshooting billing discrepancies.

Field 2: calleeE164 โ€” The Callee ID ๐Ÿ“ž

AttributeValue
๐Ÿ“Œ Field Position2
๐Ÿ“ Data TypeString (numeric E.164 format)
๐Ÿ“ DescriptionThe callee ID โ€” the destination phone number
๐Ÿ”ข Example18005559876
โš ๏ธ NotesThis is the billed destination number after prefix processing

๐Ÿ”‘ Billing relevance: The calleeE164 is the number used by the VOS3000 billing engine to match the call against rate tables. If your prefix settings strip or add digits, the calleeE164 reflects the number after those transformations. This is critical for rate table matching โ€” a calleeE164 of 18005559876 matches a different rate entry than 01118005559876.

Field 3: startTime โ€” Call Begin Time โฐ

AttributeValue
๐Ÿ“Œ Field Position3
๐Ÿ“ Data TypeDatetime string
๐Ÿ“ DescriptionBegin time of the call
๐Ÿ”ข Example2018-12-20 11:20:18
โš ๏ธ NotesFormat is YYYY-MM-DD HH:MM:SS; timezone is server local time

โฑ๏ธ Time zone awareness: The startTime is recorded in the VOS3000 server’s local timezone. If your server is configured in UTC+6 (Bangladesh Standard Time), all timestamps reflect that timezone. When integrating CDR data with systems in different timezones, always account for the offset. The startTime represents when the call was initially received by VOS3000, not when it was answered.

Field 4: stopTime โ€” Call End Time ๐Ÿ›‘

AttributeValue
๐Ÿ“Œ Field Position4
๐Ÿ“ Data TypeDatetime string
๐Ÿ“ DescriptionEnd time of the call
๐Ÿ”ข Example2018-12-20 16:34:09

๐Ÿ“Š Duration calculation: The actual call duration is stored in Field 5 (holdTime), not calculated from startTime and stopTime. The difference between startTime and stopTime includes call setup time, ringing time, and other pre-connection delays. Only holdTime represents the actual conversation duration. The stopTime determines which hourly CDR file the record is written to.

Field 5: holdTime โ€” Call Duration โฑ๏ธ

AttributeValue
๐Ÿ“Œ Field Position5
๐Ÿ“ Data TypeInteger (milliseconds)
๐Ÿ“ DescriptionCall duration in milliseconds
๐Ÿ”ข Example45000 (equals 45 seconds)
๐Ÿšจ Critical NoteValue is in MILLISECONDS, not seconds โ€” a common parsing error

โš ๏ธ The #1 parsing mistake: The holdTime field is recorded in milliseconds, not seconds. A value of 45000 means 45 seconds of conversation, not 45000 seconds. This is the single most common error when integrating VOS3000 CDR data with external billing systems. Always divide holdTime by 1000 before applying per-second or per-minute billing rates. The holdTime is also affected by the SERVER_BILLING_HOLD_TIME_PRECISION parameter, which controls millisecond rounding before billing calculation.

Field 6: endReason โ€” End Reason Code ๐Ÿ“‹

AttributeValue
๐Ÿ“Œ Field Position6
๐Ÿ“ Data TypeString/Integer
๐Ÿ“ DescriptionEnd reason โ€” SIP response code or Q.850 cause code
๐Ÿ”ข Example200 (normal), 486 (busy), 480 (no answer)

๐Ÿ” Interpreting endReason: For SIP calls, the endReason typically contains the SIP response code from the final response message (200 OK, 486 Busy, 480 Temporarily Unavailable, 503 Service Unavailable, etc.). For H.323 calls, it may contain Q.850 cause codes. The endReason field, combined with endDirection, provides the complete picture of why and how a call terminated. For a detailed breakdown of termination codes, see our guide on VOS3000 call termination reasons.

Field 7: endDirection โ€” Hangup Side ๐Ÿ”„

AttributeValue
๐Ÿ“Œ Field Position7
๐Ÿ“ Data TypeInteger (0, 1, or 2)
๐Ÿ“ DescriptionHangup side: 0 = caller, 1 = callee, 2 = server

๐Ÿ”‘ Billing impact: The endDirection tells you who initiated the call termination. A value of 0 means the calling party hung up normally, 1 means the called party hung up, and 2 means the VOS3000 server itself terminated the call (which could indicate a session timeout, account balance exhaustion, or administrative intervention). This field is critical for dispute resolution โ€” see our detailed analysis in the server hangup CDR recording guide.

Fields 8โ€“9: Gateway Identifiers ๐Ÿ“ก

FieldPositionDescriptionExample
callerGatewayId8Calling gateway ID1001
calleeGatewayId9Called gateway ID2003

๐Ÿ“ก Gateway mapping: These fields contain the VOS3000 internal gateway IDs, not the gateway names you see in the client interface. To map these IDs to human-readable gateway names, you need to cross-reference the VOS3000 gateway configuration. The callerGatewayId refers to the mapping gateway (incoming side), while the calleeGatewayId refers to the routing gateway (outgoing side). Understanding this mapping is essential for gateway performance analysis and route optimization.

Fields 10โ€“11: IP Addresses ๐ŸŒ

FieldPositionDescriptionExample
callerIp10Caller IP address192.168.1.100
calleeIp11Callee IP address10.0.0.50

๐Ÿ”’ Security value: The IP address fields are invaluable for security analysis. By tracking callerIp patterns, you can identify traffic from unexpected source IPs that may indicate unauthorized access or SIP scanning attacks. The VOS3000 anti-hack configuration uses IP-level authentication, and these CDR fields provide the audit trail for verifying that authentication is working correctly.

Fields 12โ€“13: Access (Incoming) E164 Numbers ๐Ÿ“ฅ

FieldPositionDescription
callerAccessE16412Incoming caller โ€” the original caller ID as received by VOS3000 before any transformations
calleeAccessE16413Incoming callee โ€” the original destination number as received before transformations

๐Ÿ”„ Why access fields matter: These fields preserve the original phone numbers as they arrived at VOS3000, before any callee rewrite rules, prefix stripping, or number transformations were applied. This is crucial for debugging routing issues โ€” if a call was routed incorrectly because a prefix transformation changed the destination, you can compare calleeAccessE164 (original) with calleeE164 (transformed) to identify exactly where the routing went wrong. For detailed prefix configuration guidance, see our callee rewrite rule guide.

Fields 14โ€“15: Outbound (To Gateway) E164 Numbers ๐Ÿ“ค

FieldPositionHeader NameDescription
callerToGatewayE16414callerToGatewayE164Outbound caller โ€” the caller ID sent to the outgoing gateway
calleeToGatewayE16415calleeToGatewayE164Outbound callee โ€” the destination number sent to the outgoing gateway

๐Ÿ“‹ Naming discrepancy note: The VOS3000 manual ยง4.4 header line labels these fields as callerToGatewayE164 and calleeToGatewayE164, but the field description table in the same section refers to them as “Outbound caller” and “Outbound callee” (callerOutE164 / calleeOutE164). Both names refer to the same data โ€” the phone numbers after all VOS3000 transformations have been applied, as they are sent out to the routing gateway. These outbound fields show the final form of the numbers as seen by the terminating carrier.

Field 16: calleeBilling โ€” Billing Method ๐Ÿ’ฐ

AttributeValue
๐Ÿ“Œ Field Position16
๐Ÿ“ Data TypeInteger (0 or 1)
๐Ÿ“ DescriptionBilling method: 0 = By caller, 1 = By callee

๐Ÿ’ก Understanding billing method: This field indicates which party’s account is charged for the call. A value of 0 means the caller’s account is billed (the standard arrangement for most calls). A value of 1 means the callee’s account is billed, which applies to collect calls, toll-free number calls, or special reverse-charging arrangements. This field works in conjunction with billingMode (Field 17) to determine the complete billing attribution for each call.

Field 17: billingMode โ€” Charge Mode ๐Ÿ’ณ

AttributeValue
๐Ÿ“Œ Field Position17
๐Ÿ“ Data TypeInteger (-1, 0, 1, or 3)
๐Ÿ“ DescriptionCharge mode: -1 = no billing, 0 = phone number, 1 = gateway ID, 3 = phone card

๐Ÿ”‘ Billing mode codes explained: This is one of the most important fields for billing analysis. A billingMode of -1 means the call was not billed at all โ€” this applies to illegal calls, free numbers, and calls that bypass the billing engine. A value of 0 means billing is attributed to a phone number account. A value of 1 means billing is attributed to a gateway ID. A value of 3 means billing is attributed to a phone card (calling card). For a comprehensive breakdown of how each code affects billing calculations, refer to our detailed billing mode codes reference.

Fields 18โ€“19: Post-Dial Delay Metrics โฑ๏ธ

FieldPositionDescription
callerPdd18Time elapsed from call received to call connected (incoming PDD)
calleePdd19Time elapsed from call sent to routing response (outgoing PDD)

๐Ÿ“Š PDD analysis value: Post-Dial Delay is a critical quality-of-service metric. High callerPdd values indicate that calls take too long to connect on the incoming side, which frustrates callers. High calleePdd values indicate slow response from routing gateways, which may point to gateway overload, network latency, or incorrect INVITE timeout configuration. Monitoring PDD trends helps you identify degrading gateway performance before it impacts your ASR.

๐Ÿ“‹ Complete VOS3000 CDR Pipe Format Quick Reference Table

#Field NameTypeDescriptionExample
1callerE164StringThe caller ID12125551234
2calleeE164StringThe callee ID18005559876
3startTimeDatetimeCall begin time2018-12-20 11:20:18
4stopTimeDatetimeCall end time2018-12-20 16:34:09
5holdTimeInteger (ms)Call duration in milliseconds45000
6endReasonString/IntEnd reason code200
7endDirectionIntegerHangup side (0/1/2)0
8callerGatewayIdIntegerCalling gateway1001
9calleeGatewayIdIntegerCalled gateway2003
10callerIpStringCaller IP address192.168.1.100
11calleeIpStringCallee IP address10.0.0.50
12callerAccessE164StringIncoming caller12125551234
13calleeAccessE164StringIncoming callee01118005559876
14callerToGatewayE164StringOutbound caller12125551234
15calleeToGatewayE164StringOutbound callee18005559876
16calleeBillingIntegerBilling method (0/1)0
17billingModeIntegerCharge mode (-1/0/1/3)0
18callerPddIntegerIncoming PDD (ms)3200
19calleePddIntegerOutgoing PDD (ms)1500

๐Ÿ“Š External System Mapping Guide – VOS3000 CDR Pipe

๐Ÿ”— When integrating VOS3000 CDR data with external billing and analytics systems, field names and data types often need to be mapped to the target system’s schema. Here is a reference mapping for common integration targets:

VOS3000 FieldMySQL ColumnCommon Billing LabelTransform Needed
callerE164VARCHAR(32)ANI / Calling NumberNone
calleeE164VARCHAR(32)DNIS / Called NumberNone
startTimeDATETIMECall Start / Setup TimeParse datetime string
holdTimeINTDuration (seconds)โš ๏ธ Divide by 1000
endReasonVARCHAR(16)Release CauseMap to cause code table
endDirectionTINYINTRelease SourceMap 0/1/2 to labels
billingModeTINYINTBilling TypeMap -1/0/1/3 to labels

โ“ Frequently Asked Questions

โ“ How many fields are in the VOS3000 CDR pipe format?

๐Ÿ“‹ The VOS3000 CDR pipe format contains 17 core billing-critical fields (through the billingMode field at position 17) plus 2 Post-Dial Delay fields (callerPdd at position 18 and calleePdd at position 19), for a total of up to 19 fields. The pipe delimiter creates 18 separators for the full 19-column format. Older VOS3000 versions may produce records with only 17 fields (without PDD data). Your parsing code should handle variable field counts gracefully by checking the number of pipe-delimited columns in each line before processing.

โ“ Why is holdTime in milliseconds instead of seconds?

โฑ๏ธ VOS3000 records holdTime in milliseconds to support high-precision billing configurations. The SERVER_BILLING_FEE_PRECISTION and SERVER_BILLING_HOLD_TIME_PRECISION parameters allow billing calculations down to millisecond granularity. While most operators bill in whole seconds or minutes, the millisecond precision in the CDR ensures that no rounding is applied before the data is exported โ€” any rounding happens in the billing engine according to the configured precision parameters. When parsing CDR data, always divide holdTime by 1000 to convert to seconds.

โ“ What is the difference between callerE164 and callerAccessE164?

๐Ÿ”„ callerE164 (Field 1) is the caller ID after VOS3000 has applied all prefix transformations and number manipulations. callerAccessE164 (Field 12) is the original incoming caller ID as it was received by VOS3000 before any transformations. The two values differ when VOS3000’s callee rewrite rules, prefix stripping, or caller ID manipulation features modify the number. Similarly, calleeE164 (Field 2) may differ from calleeAccessE164 (Field 13) when the destination number is transformed before routing.

โ“ What does a billingMode of -1 mean in the CDR?

๐Ÿ’ณ A billingMode of -1 means the call was not billed. This applies to calls that bypass the billing engine entirely, including illegal calls from unauthorized IP addresses, calls to toll-free numbers configured under SERVER_BILLING_FREE_E164S, and calls where the billing system could not determine an account to charge. These records still appear in the CDR export (when SS_CDR_RECORD_ILLEGAL is On) for security auditing purposes, but they carry no billing charge.

โ“ How do I parse VOS3000 CDR files with different field counts?

๐Ÿ”ง The safest approach is to split each CDR line on the pipe character and check the resulting field count before processing. Lines with 17 fields contain core billing data without PDD metrics. Lines with 19 fields include the PDD columns. Always map fields by position (index), not by counting from the end, since new fields are added at the end of the line. Use the field position reference table in this guide to ensure correct mapping regardless of the field count in your specific VOS3000 version.

โ“ Are VOS3000 CDR timestamps in UTC or local time?

โฐ VOS3000 CDR timestamps (startTime and stopTime) are recorded in the server’s local timezone, not UTC. If your server is configured with timezone Asia/Dhaka (UTC+6), all timestamps will be in BST. When integrating CDR data with systems that expect UTC, you must apply the appropriate timezone offset during parsing. Always verify your server’s timezone setting with the date command in SSH before assuming the timezone in your CDR processing logic.

๐Ÿ“ž Need Expert Help with VOS3000 CDR Pipe Format?

๐Ÿ”ง Accurate VOS3000 CDR pipe format parsing is the foundation of every billing integration, analytics pipeline, and compliance archive. A single misinterpreted field โ€” especially the millisecond holdTime or the billing mode codes โ€” can cascade into revenue-impacting billing errors. Whether you are building a CDR parser from scratch, troubleshooting field mapping issues, or integrating VOS3000 with an external billing platform, expert guidance ensures your data pipeline is accurate from day one. ๐Ÿ“Š

๐Ÿ’ฌ WhatsApp: +8801911119966 โ€” Get immediate assistance with VOS3000 CDR pipe format parsing, field mapping, and external system integration. Our team specializes in VOS3000 CDR data extraction, billing system integration, and custom analytics development. ๐Ÿ”ง

๐Ÿ”— Explore related VOS3000 CDR and configuration guides:


๐Ÿ“ž Need Professional VOS3000 Setup Support?

For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:

๐Ÿ“ฑ WhatsApp: +8801911119966
๐ŸŒ Website: www.vos3000.com
๐ŸŒ Blog: multahost.com/blog
๐Ÿ“ฅ Downloads: VOS3000 Downloads


VOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction CriticalVOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction CriticalVOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction Critical
VOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction Critical

VOS3000 CDR File Rotation Robust Backup Write Interval Best Configuration

VOS3000 CDR File Rotation Robust Backup Write Interval Configuration

๐Ÿ“‹ Every VoIP operator knows that CDR data is the lifeblood of billing reconciliation โ€” lose your call records, and you lose revenue. The VOS3000 CDR file rotation system, controlled by SERVER_CDR_FILE_WRITE_INTERVAL and SERVER_CDR_FILE_WRITE_MAX, provides a robust backup mechanism that writes call records to text files independently of the primary database. When configured correctly, this ensures you always have a secondary copy of every CDR โ€” even during database outages, server restarts, or unexpected failures. ๐Ÿ›ก๏ธ

โš ๏ธ But misconfigure the rotation parameters, and you risk two catastrophic outcomes: disk overflow from uncontrolled CDR file accumulation, or missing records if the rotation window is too long during peak traffic. The VOS3000 CDR file rotation parameters give you precise control over how frequently backup files are generated and how many are retained โ€” balancing data integrity against disk consumption. This guide covers every detail from the official VOS3000 2.1.9.07 manual, with no fabricated values. ๐Ÿ”ง

๐ŸŽฏ Need help configuring your VOS3000 CDR backup? Contact our team at WhatsApp: +8801911119966 for expert assistance with CDR rotation, billing setup, and complete VOS3000 deployment. ๐Ÿ’ฌ

Table of Contents

๐Ÿ” What Is VOS3000 CDR File Rotation?

๐Ÿ“Š The VOS3000 CDR file rotation system is an additional backup mechanism that writes call detail records to plain text files on the server filesystem. This operates alongside the primary CDR database, providing redundancy and enabling external analytics integration. The system generates pipe-delimited text files in the cdr directory beneath the VOS3000 installation directory, with one file created per configured time interval. ๐Ÿ“

๐Ÿ’ก Why this matters: The backup CDR file system serves several critical purposes:

  • ๐Ÿ›ก๏ธ Disaster recovery: If the database becomes corrupted or unavailable, text files remain intact on disk
  • ๐Ÿ“Š External analytics: Pipe-delimited files are easy to parse with Python, awk, or business intelligence tools
  • ๐Ÿ”„ Regulatory compliance: Many telecom regulators require CDR archival in flat-file format
  • ๐Ÿ’ฐ Billing reconciliation: Compare database CDRs against file CDRs to detect discrepancies
  • ๐Ÿ“ก Real-time monitoring: Some operators tail the CDR files for live traffic visibility

๐Ÿ”‘ Key distinction: The VOS3000 CDR file rotation is a backup mechanism. It does not replace the database CDR storage. The primary CDR records are always written to the database first; the file-based system creates a secondary copy that can be used independently.

โš™๏ธ SERVER_CDR_FILE_WRITE_INTERVAL โ€” The Core Parameter

โฑ๏ธ SERVER_CDR_FILE_WRITE_INTERVAL defines the time interval (in seconds) at which the softswitch creates new CDR text files. Each time this interval elapses, a new file is opened and the previous file is finalized for reading. ๐Ÿ“‹

AttributeValue
๐Ÿ“Œ Parameter NameSERVER_CDR_FILE_WRITE_INTERVAL
๐Ÿ”ข Default ValueNone (not set by default)
๐Ÿ“ UnitSeconds
๐Ÿ“ Range60โ€“86400
๐Ÿ“ DescriptionAdditional write call record file, the new file created time interval (seconds)
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter

๐Ÿ’ก How the interval works: When you set SERVER_CDR_FILE_WRITE_INTERVAL to a value such as 3600 (1 hour), the softswitch creates a new CDR text file every hour. All CDRs whose end time falls within that hour are written to the corresponding file. At the end of the interval, the file is closed and a new one is opened. The file naming convention follows the format YYYYMMDDHH.txt โ€” for example, 2026042612.txt contains all CDRs that ended between 12:00 and 13:00 on April 26, 2026.

๐ŸŽฏ Interval Value Recommendations by Traffic Volume

๐Ÿ“ก The optimal interval depends heavily on your call volume. Higher traffic demands shorter intervals to prevent individual files from becoming too large: ๐Ÿ’ก

Traffic VolumeRecommended IntervalSeconds ValueRationale
๐Ÿ“ž Low (<50 CPS)1 hour3600โœ… Manageable file size; hourly granularity
๐Ÿ“Š Medium (50โ€“200 CPS)30 minutes1800๐Ÿ”ง Prevents oversized files during peaks
๐Ÿ”ฅ High (200+ CPS)15 minutes900๐Ÿ›ก๏ธ Keeps files manageable; easier parsing
โš ๏ธ Extreme (DDoS scenario)5 minutes300๐Ÿšจ Rapid rotation prevents disk fill

โš ๏ธ Important: The minimum allowed value is 60 seconds and the maximum is 86400 seconds (24 hours). Setting the interval below 60 seconds is not supported. If your traffic is so high that even 5-minute files are too large, consider increasing SERVER_CDR_FILE_WRITE_MAX to retain more files, or implementing an external script that periodically archives old files to remote storage.

๐Ÿ“ฆ SERVER_CDR_FILE_WRITE_MAX โ€” Rotation File Count Limit

๐Ÿ“ While SERVER_CDR_FILE_WRITE_INTERVAL controls how often new files are created, SERVER_CDR_FILE_WRITE_MAX controls how many backup CDR files are retained on disk. This parameter prevents uncontrolled disk consumption by automatically deleting the oldest files when the count exceeds the limit. ๐Ÿ—‘๏ธ

AttributeValue
๐Ÿ“Œ Parameter NameSERVER_CDR_FILE_WRITE_MAX
๐Ÿ”ข Default Value2048
๐Ÿ“ UnitNumber of files
๐Ÿ“ Range10โ€“4096
๐Ÿ“ DescriptionAdditional write call record file, the maximum number of reserved file
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter

๐Ÿ”„ How rotation works: When the number of CDR text files exceeds SERVER_CDR_FILE_WRITE_MAX, the oldest files are automatically deleted. This creates a sliding window of retained CDR data โ€” at any given time, you have at most the most recent N files on disk, where N equals SERVER_CDR_FILE_WRITE_MAX.

๐Ÿ“Š Calculating Retention Period from Rotation Parameters

๐Ÿงฎ The total retention period depends on both the write interval and the maximum file count. Here is the formula: ๐Ÿ’ก

๐Ÿ“‹ VOS3000 CDR File Retention Calculation:

Retention Period = SERVER_CDR_FILE_WRITE_INTERVAL ร— SERVER_CDR_FILE_WRITE_MAX

Example 1 (Default Settings):
  Interval = 3600s (1 hour)  ร—  Max Files = 2048
  Retention = 3600 ร— 2048 = 7,372,800 seconds โ‰ˆ 85.3 days

Example 2 (High Traffic):
  Interval = 1800s (30 min)  ร—  Max Files = 2048
  Retention = 1800 ร— 2048 = 3,686,400 seconds โ‰ˆ 42.7 days

Example 3 (Maximum Retention):
  Interval = 86400s (24 hours)  ร—  Max Files = 4096
  Retention = 86400 ร— 4096 = 353,894,400 seconds โ‰ˆ 11.2 years

Example 4 (Short Retention, Frequent Rotation):
  Interval = 300s (5 min)  ร—  Max Files = 2048
  Retention = 300 ร— 2048 = 614,400 seconds โ‰ˆ 7.1 days

โš ๏ธ Critical warning: A shorter interval with the same file count means shorter total retention. If you decrease the interval for performance reasons, you must proportionally increase the file count to maintain the same retention period. Otherwise, you may lose historical CDR backup data faster than expected. ๐Ÿ”ฅ

๐Ÿ–ฅ๏ธ Enabling VOS3000 CDR File Rotation

๐Ÿ”ง The VOS3000 CDR file rotation requires two conditions to be met before it generates backup files: the SS_CDR_RECORD_TO_FILE parameter must be enabled, and the SERVER_CDR_FILE_WRITE_INTERVAL must be set to a valid value. ๐Ÿ“‹

Step 1: Enable CDR Text File Export ๐Ÿ“„

  1. ๐Ÿ” Log in to VOS3000 Client
  2. ๐Ÿ“Œ Navigate: Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter
  3. ๐Ÿ” Locate SS_CDR_RECORD_TO_FILE
  4. โœ๏ธ Set value to On
AttributeValue
๐Ÿ“Œ Parameter NameSS_CDR_RECORD_TO_FILE
๐Ÿ”ข Default ValueOff
๐Ÿ“ DescriptionSave CDR as TXT โ€” enables the backup CDR text file system
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter

Step 2: Configure Write Interval โฑ๏ธ

  1. ๐Ÿ“Œ Navigate: Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter
  2. ๐Ÿ” Locate SERVER_CDR_FILE_WRITE_INTERVAL
  3. โœ๏ธ Set the desired interval value (60โ€“86400 seconds) based on your traffic volume

Step 3: Configure Maximum File Count ๐Ÿ“

  1. ๐Ÿ” In the same Server parameter section, locate SERVER_CDR_FILE_WRITE_MAX
  2. โœ๏ธ Set the maximum number of files to retain (10โ€“4096, default: 2048)
  3. ๐Ÿ’พ Save and apply the configuration

Step 4: Verify CDR File Generation โœ…

๐Ÿ–ฅ๏ธ After configuration, verify that files are being generated in the CDR directory:

# Check the CDR directory on the VOS3000 server
ls -la /home/vos3000/cdr/

# Expected output โ€” files named by YYYYMMDDHH convention:
# -rw-r--r-- 1 vos3000 vos3000  245120 Apr 26 12:00 2026042612.txt
# -rw-r--r-- 1 vos3000 vos3000  189340 Apr 26 13:00 2026042613.txt
# -rw-r--r-- 1 vos3000 vos3000  312500 Apr 26 14:00 2026042614.txt

# Verify rotation is working โ€” old files should be auto-deleted
# when count exceeds SERVER_CDR_FILE_WRITE_MAX
ls -1 /home/vos3000/cdr/ | wc -l

๐Ÿ“Š For detailed CDR file format information, see our VOS3000 CDR pipe format reference guide.

๐Ÿ”„ VOS3000 CDR File Rotation and Disk Space Management

๐Ÿ’พ One of the most critical aspects of VOS3000 CDR file rotation is managing disk space consumption. Each CDR record written to the text file contains 18 pipe-delimited fields. A typical single CDR line is approximately 200โ€“350 bytes depending on the length of phone numbers, IP addresses, and other variable-length fields. ๐Ÿ“

๐Ÿ“ Estimating Disk Space Requirements

๐Ÿ“Š Use this calculation to estimate your CDR file storage needs: ๐Ÿ’ก

MetricFormulaExample (100 CPS)
CDR lines per hourCPS ร— 3600360,000
File size per hourLines ร— 300 bytes (avg)~108 MB/hour
Daily disk usageFile/hour ร— 24~2.6 GB/day
With 2048 hourly files2048 ร— 108 MB~221 GB total

โš ๏ธ Key insight: At 100 CPS with hourly intervals and the default 2048 file limit, you need approximately 221 GB of disk space for CDR files alone. This does not account for the database, logs, or other system files. Ensure your server has adequate storage, or implement an external archival strategy. For help sizing your VOS3000 server, see our concurrent call load test guide. ๐Ÿ”ง

๐Ÿ›ก๏ธ Common VOS3000 CDR File Rotation Problems and Solutions

โŒ Misconfigured rotation parameters cause a range of issues from missing records to disk overflow. Here are the most common problems and their solutions: ๐Ÿ”

โŒ Problem 1: CDR Files Not Being Generated

๐Ÿ” Symptom: The CDR directory exists but no text files are being created, even though calls are flowing through the system.

๐Ÿ’ก Cause: The most common reason is that SS_CDR_RECORD_TO_FILE is set to Off (default). Without enabling this parameter, the VOS3000 CDR file rotation system is completely inactive regardless of the interval and max file settings.

โœ… Solutions:

  • ๐Ÿ”ง Set SS_CDR_RECORD_TO_FILE to On in Softswitch parameter settings
  • ๐Ÿ“Š Verify SERVER_CDR_FILE_WRITE_INTERVAL is set to a valid value between 60 and 86400
  • ๐Ÿ“ Check that the cdr directory exists beneath the VOS3000 installation directory and has write permissions
  • ๐Ÿ” Check the softswitch logs for any write errors

โŒ Problem 2: Disk Space Exhausting Rapidly

๐Ÿ” Symptom: The server runs out of disk space quickly, and the CDR directory contains a very large number of files.

๐Ÿ’ก Cause: SERVER_CDR_FILE_WRITE_MAX is set too high, or the write interval is very short, causing many small files that collectively consume large amounts of disk space. Alternatively, the automatic file deletion mechanism may not be working correctly.

โœ… Solutions:

  • ๐Ÿ“ Reduce SERVER_CDR_FILE_WRITE_MAX to a value that fits within your available disk space
  • โฑ๏ธ Increase SERVER_CDR_FILE_WRITE_INTERVAL to create fewer, larger files
  • ๐Ÿ”„ Implement an external archival script that moves old CDR files to remote storage (NFS, S3, etc.)
  • ๐Ÿ“Š Monitor disk usage with a cron job that alerts you when usage exceeds 80%

โŒ Problem 3: Historical CDR Files Disappearing Too Quickly

๐Ÿ” Symptom: You need to look up CDR data from 30 days ago, but the oldest available file is only from 10 days ago.

๐Ÿ’ก Cause: The retention period (interval ร— max files) is shorter than your required retention window. This happens when the interval is decreased without proportionally increasing the file count.

โœ… Solutions:

  • ๐Ÿ“ Calculate your required retention: Required Max Files = Required Days ร— 86400 / Interval
  • ๐Ÿ“ฆ Increase SERVER_CDR_FILE_WRITE_MAX to the calculated value (up to 4096 maximum)
  • ๐Ÿ—„๏ธ If you need more than 4096 files, implement external archival before rotation deletes them
  • ๐Ÿ“‹ For detailed CDR querying guidance, see our VOS3000 CDR analysis and billing guide

โŒ Problem 4: Zero-Duration Calls Flooding CDR Files

๐Ÿ” Symptom: CDR text files are much larger than expected, filled with records for calls that never connected (0-second duration).

๐Ÿ’ก Cause: The SS_CDR_RECORD_NONCONNECT parameter is set to On, causing all non-connected calls (failed attempts, busy, no answer) to be included in the text file export along with successful calls.

โœ… Solutions:

  • โš™๏ธ Set SS_CDR_RECORD_NONCONNECT to Off to exclude zero-duration calls from the file export
  • ๐Ÿ“Š Keep it On only if you need failed call data for analytics or fraud detection
  • ๐Ÿ›ก๏ธ During DDoS attacks, set SERVER_BILLING_RECORD_ZERO_HOLD_TIME to Off to prevent database overload โ€” see our DDoS protection guide

๐Ÿ“‹ Complete VOS3000 CDR File Rotation Parameter Reference

๐Ÿ“Š Here is the complete reference table for all parameters related to CDR file rotation, sourced from the official VOS3000 2.1.9.07 manual: ๐Ÿ”ง

ParameterDefaultRangePurpose
SERVER_CDR_FILE_WRITE_INTERVALNone60โ€“86400sTime interval for new CDR file creation
SERVER_CDR_FILE_WRITE_MAX204810โ€“4096Maximum number of CDR files to retain
SS_CDR_RECORD_TO_FILEOffOn/OffEnable/disable CDR text file export
SS_CDR_RECORD_NONCONNECTOffOn/OffInclude non-connected calls (0s) in file export
SS_CDR_RECORD_ILLEGALOnOn/OffRecord illegal calls in CDR files
SERVER_CDR_REAL_TIME_REPORT_SERVERNoneIP:PortForward CDRs to external server in real-time

๐Ÿ“ All server parameters are located at: Navigation โ†’ Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter. Softswitch parameters are at the same path under Softswitch parameter.

๐Ÿ’ก VOS3000 CDR File Rotation Best Practices

๐ŸŽฏ Follow these best practices to ensure your VOS3000 CDR file rotation is both reliable and efficient: ๐Ÿ“‹

Best PracticeRecommendationReason
๐Ÿ“Š Calculate retention needsInterval ร— Max Files = Retentionโœ… Ensures you keep enough historical data
๐Ÿ“ Implement external archivalCron job to copy old files to remote storage๐Ÿ›ก๏ธ Prevents data loss when rotation deletes files
โฑ๏ธ Match interval to trafficHigher CPS = shorter interval๐Ÿ”ง Keeps individual file sizes manageable
๐Ÿ’พ Monitor disk spaceAlert at 80% usage threshold๐Ÿšจ Prevents unexpected disk-full outages
๐Ÿ”„ Test recovery regularlyParse backup files monthly to verify integrity๐Ÿ“‹ Confirms files are usable when needed
๐Ÿ” Secure CDR directoryRestrict file permissions to vos3000 user only๐Ÿ›ก๏ธ CDRs contain sensitive billing data

๐Ÿ’ฌ Questions about your VOS3000 CDR file rotation setup? Reach out at WhatsApp: +8801911119966 โ€” our VOS3000 experts can help you optimize rotation settings for your traffic volume and retention requirements. ๐Ÿ“ž

โ“ Frequently Asked Questions

โ“ What is the default value for SERVER_CDR_FILE_WRITE_INTERVAL?

๐Ÿ“‹ The default value for SERVER_CDR_FILE_WRITE_INTERVAL is None (not set). This means that CDR file rotation is not active by default. You must explicitly set a value between 60 and 86400 seconds and enable SS_CDR_RECORD_TO_FILE to On before the system generates backup CDR text files. Without this configuration, CDR records are only stored in the database. ๐Ÿ’ก

โ“ How does VOS3000 CDR file rotation prevent disk overflow?

๐Ÿ›ก๏ธ The VOS3000 CDR file rotation uses SERVER_CDR_FILE_WRITE_MAX to enforce a maximum number of retained files. When the file count exceeds this limit, the oldest files are automatically deleted. For example, with the default value of 2048 and an hourly interval, the system retains approximately 85 days of CDR files. Once the 2049th file is created, the oldest file is removed, maintaining a consistent disk footprint. This sliding window mechanism ensures the CDR directory never grows beyond a predictable size. ๐Ÿ“

โ“ Can I change the VOS3000 CDR file rotation interval without restarting?

๐Ÿ”ง Server parameters in VOS3000 typically take effect after saving and applying the configuration through the VOS3000 Client interface. While some parameters may apply immediately, it is recommended to verify that the new interval is in effect by checking the timestamps of newly created CDR files. If the old interval persists, a softswitch service restart may be required. Always test configuration changes during a maintenance window to avoid any disruption to CDR recording. ๐Ÿ“Š

โ“ What is the relationship between SS_CDR_RECORD_TO_FILE and SERVER_CDR_FILE_WRITE_INTERVAL?

๐Ÿ”— SS_CDR_RECORD_TO_FILE is the master switch that enables or disables the entire CDR text file system. SERVER_CDR_FILE_WRITE_INTERVAL controls the frequency of file creation within that system. If SS_CDR_RECORD_TO_FILE is Off (default), no CDR files are generated regardless of the interval setting. If it is On but the interval is not set (None), the system may not create files properly. Both parameters must be correctly configured for the VOS3000 CDR file rotation to function. ๐ŸŽฏ

โ“ How do I include non-connected calls in the CDR text files?

๐Ÿ“Š By default, SS_CDR_RECORD_NONCONNECT is set to Off, which means only successfully connected calls (calls with duration greater than 0 seconds) are written to the CDR text files. To include failed call attempts, busy calls, and no-answer calls, set SS_CDR_RECORD_NONCONNECT to On. Be aware that enabling this parameter significantly increases the number of CDR records per file, especially during traffic spikes or attack scenarios. For DDoS protection guidance, see our zero duration CDR control guide. โš ๏ธ

โ“ Where are VOS3000 CDR text files stored on the server?

๐Ÿ“ CDR text files are stored in the cdr directory beneath the VOS3000 installation directory. The file naming convention is YYYYMMDDHH.txt, where YYYY is the year, MM is the month, DD is the day, and HH is the hour. Each file contains all CDRs whose end time falls within that time window. For example, 2026042614.txt contains CDRs for calls that ended between 14:00 and 15:00 on April 26, 2026. The files use pipe-delimited format with 18 fields per record โ€” see our CDR pipe format reference for complete field documentation. ๐Ÿ“‹

๐Ÿ“ž Need Expert Help with VOS3000 CDR File Rotation?

๐Ÿ”ง Proper VOS3000 CDR file rotation configuration is essential for ensuring billing data integrity, meeting regulatory retention requirements, and preventing disk overflow disasters. Whether you need to set up CDR backup for the first time, tune rotation parameters for high traffic, or implement an external archival strategy, our VOS3000 experts are here to help. ๐Ÿ›ก๏ธ

๐Ÿ’ฌ Contact us at WhatsApp: +8801911119966 for professional VOS3000 deployment, CDR configuration, and ongoing support. We help VoIP operators worldwide optimize their softswitch performance and billing accuracy. ๐ŸŒ

๐Ÿ“– Explore more VOS3000 guides: CDR analysis and billing, billing system overview, and parameter description reference. ๐Ÿ”—


๐Ÿ“ž Need Professional VOS3000 Setup Support?

For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:

๐Ÿ“ฑ WhatsApp: +8801911119966
๐ŸŒ Website: www.vos3000.com
๐ŸŒ Blog: multahost.com/blog
๐Ÿ“ฅ Downloads: VOS3000 Downloads


VOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction CriticalVOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction CriticalVOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction Critical