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 Text File Export Complete Pipe-Delimited Format Best Guide

VOS3000 CDR Text File Export Complete Pipe-Delimited Format Guide

๐Ÿ“Š Every VoIP operator needs reliable call data โ€” and the VOS3000 CDR text file export is the backbone of billing accuracy, traffic analysis, and regulatory compliance. When enabled, VOS3000 generates pipe-delimited text files containing every call detail record, ready for ingestion by external billing systems, analytics platforms, and fraud detection tools. Yet many operators never configure this powerful feature correctly, leaving critical data trapped inside the VOS3000 database with no external backup or integration path. ๐Ÿ“

โš™๏ธ The two parameters that control this entire process โ€” SS_CDR_RECORD_TO_FILE and SS_CDR_RECORD_NONCONNECT โ€” are straightforward to configure, but their implications for disk space, data completeness, and billing accuracy are often misunderstood. Setting SS_CDR_RECORD_TO_FILE to On creates an hourly CDR text file in the softswitch’s cdr/ directory, while SS_CDR_RECORD_NONCONNECT determines whether zero-duration calls (failed attempts, busy signals, no-answer) are included in that export. The difference between having these records and not having them can mean the difference between catching a fraud pattern early and discovering it weeks too late. ๐Ÿ”

๐ŸŽฏ This guide provides a complete walkthrough of the VOS3000 CDR text file export system: how to enable it, how the pipe-delimited format is structured, how file naming and rotation work, and how to integrate the exported data with external systems. All parameter details are sourced from the official VOS3000 2.1.8.0/2.1.9.07 English manual, ยง4.3.5.1 (page 225) and ยง4.4 (pages 241โ€“243). ๐Ÿ“˜

Table of Contents

๐Ÿ” What Is VOS3000 CDR Text File Export?

๐Ÿ“ The VOS3000 CDR text file export is a softswitch-level feature that writes call detail records to flat text files on the server filesystem. Unlike CDR records stored in the MySQL database โ€” which require the VOS3000 client or web interface to query โ€” text file exports provide a continuous, externally accessible stream of call data that can be consumed by any system capable of parsing pipe-delimited text. ๐Ÿ“‹

๐Ÿ’ก Why text file export matters:

  • ๐Ÿ”„ External billing integration: Feed CDR data directly into third-party billing platforms without database access
  • ๐Ÿ›ก๏ธ Backup redundancy: Maintain a file-based CDR copy independent of the MySQL database
  • ๐Ÿ“Š Analytics pipeline: Pipe-delimited files are easily consumed by Python, Excel, BigQuery, and custom tools
  • ๐Ÿ” Fraud detection: Real-time or near-real-time CDR analysis on exported files catches anomalies faster
  • ๐Ÿ“‹ Regulatory compliance: Many telecom regulators require CDR archival in a portable, non-proprietary format
  • ๐Ÿ”— System migration: Export historical CDR data when migrating to a new billing or CRM system

๐Ÿ“ Parameter location in VOS3000 Client: Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter

๐Ÿ“‹ SS_CDR_RECORD_TO_FILE โ€” The Master Switch

๐Ÿ”ง SS_CDR_RECORD_TO_FILE is the primary parameter that enables or disables the entire text file CDR export. When set to On, VOS3000 creates hourly text files containing all CDR records in pipe-delimited format.

AttributeValue
๐Ÿ“Œ Parameter NameSS_CDR_RECORD_TO_FILE
๐Ÿ”ข Default ValueOff
โš™๏ธ Valid ValuesOn / Off
๐Ÿ“ DescriptionSave CDR as TXT (per VOS3000 manual ยง4.3.5.1, page 225)
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter

โš ๏ธ Critical note: This parameter is Off by default. Many VOS3000 deployments run for years without CDR text file export enabled, which means no file-based CDR backup exists. If the MySQL database becomes corrupted or the server experiences a disk failure, all historical CDR data stored only in the database may be lost. Enabling SS_CDR_RECORD_TO_FILE provides a critical safety net.

๐Ÿ“‹ SS_CDR_RECORD_NONCONNECT โ€” Zero-Duration Call Export

๐Ÿ“ž SS_CDR_RECORD_NONCONNECT controls whether non-connected calls โ€” those with zero hold time โ€” are included in the text file export. This includes busy signals, no-answer attempts, failed calls, and other call attempts that never established a two-way audio path.

AttributeValue
๐Ÿ“Œ Parameter NameSS_CDR_RECORD_NONCONNECT
๐Ÿ”ข Default ValueOff
โš™๏ธ Valid ValuesOn / Off
๐Ÿ“ DescriptionWhen saving CDR as TXT, contains CDR which hold time is 0s (per VOS3000 manual ยง4.3.5.1, page 225)
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter

๐Ÿ’ก Why you might want non-connected CDRs: While zero-duration calls generate no revenue, they carry essential operational intelligence. High volumes of busy signals from a specific gateway may indicate capacity problems. Repeated no-answer attempts to a destination could signal a routing misconfiguration. Patterns of failed calls from unauthorized IPs โ€” tracked by SS_CDR_RECORD_ILLEGAL โ€” are often the first sign of toll fraud. Without SS_CDR_RECORD_NONCONNECT enabled, all of this intelligence is excluded from your text file export.

๐Ÿ“ CDR Text File Naming and Storage

๐Ÿ“‚ When SS_CDR_RECORD_TO_FILE is enabled, VOS3000 creates CDR text files in the cdr/ directory under the VOS3000 installation path. The naming convention follows a precise hourly pattern documented in the official manual ยง4.4 (page 241):

๐Ÿ“‹ File Naming Convention

AttributeDetail
๐Ÿ“ FormatYYYYMMDDHH.txt
๐Ÿ“ Directorycdr/ under VOS3000 installation path
โฐ GranularityOne file per hour
๐Ÿ“ Example2013103112.txt contains CDRs ending between 12:00:00 and 12:59:59

๐Ÿ” How the hourly file system works: Each CDR is written to the file corresponding to the hour in which the call ended (stop time). A call that starts at 11:45 and ends at 12:10 will be recorded in the 12:00 hour file, not the 11:00 hour file. This means each file contains a self-contained set of CDRs that can be processed independently without worrying about time-overlap between files.

๐Ÿ“‹ CDR File Rotation and Retention

๐Ÿ”„ VOS3000 manages CDR text file rotation using two server-level parameters that control how long files are retained and how many are kept on disk:

ParameterDefaultRangePurpose
SERVER_CDR_FILE_WRITE_INTERVALNone60โ€“86400 secondsTime interval for creating new CDR files
SERVER_CDR_FILE_WRITE_MAX204810โ€“4096 filesMaximum number of CDR files retained on disk

๐Ÿ“Š Disk space planning: With the default SERVER_CDR_FILE_WRITE_MAX of 2048 files and one file per hour, VOS3000 retains approximately 85 days of CDR text files. For high-traffic systems, monitor disk usage closely โ€” each hourly file can range from a few KB on a low-traffic system to hundreds of MB on a system processing thousands of concurrent calls. To learn more about CDR file rotation and backup strategies, see our guide on VOS3000 CDR analysis and billing.

๐Ÿ“Š Pipe-Delimited CDR Format Overview

๐Ÿ”— Each line in the VOS3000 CDR text file represents one call detail record, with fields separated by the pipe character (|). The format is documented in the official VOS3000 manual ยง4.4 (pages 241โ€“243). Understanding this format is essential for parsing CDR data into external systems.

๐Ÿ“‹ CDR Line Format Structure

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 pipe-delimited format with 18 pipe separators, resulting in 19 columns of data. The first 18 fields (through billingMode) are the core CDR fields present in all versions, while the callerPdd and calleePdd fields provide Post-Dial Delay metrics that were added in later revisions of the software.

๐Ÿ“‹ Key CDR Fields at a Glance

#FieldDescriptionExample
1callerE164The caller ID12125551234
2calleeE164The callee ID18005559876
3startTimeCall begin time2018-12-20 11:20:18
4stopTimeCall end time2018-12-20 16:34:09
5holdTimeCall duration in milliseconds45000
6endReasonEnd reason code200
7endDirectionHangup side (0=caller, 1=callee, 2=server)0
17billingModeCharge mode (-1=no billing, 0=phone, 1=gateway, 3=phone card)0

๐Ÿ”‘ Key observations: The holdTime field records call duration in milliseconds, not seconds. This is critical for billing calculations โ€” a holdTime of 45000 means 45 seconds, not 45000 seconds. The endDirection field identifies who terminated the call (caller, callee, or server), which is essential for call termination analysis. The billingMode field determines how the call was charged and whether billing was applied at all.

โš™๏ธ Step-by-Step VOS3000 CDR Text File Export Configuration

๐Ÿ–ฅ๏ธ Follow these steps to enable and configure the VOS3000 CDR text file export on your softswitch:

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

  1. ๐Ÿ” Log in to VOS3000 Client with administrator credentials
  2. ๐Ÿ“Œ Navigate: Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter
  3. ๐Ÿ” Locate SS_CDR_RECORD_TO_FILE in the parameter list
  4. โœ๏ธ Change the value from Off to On
  5. ๐Ÿ’พ Click Save to apply the configuration

โš ๏ธ Important: After enabling SS_CDR_RECORD_TO_FILE, VOS3000 will begin writing CDR text files starting from the next hourly interval. Historical CDR data from before the parameter was enabled is not retroactively exported. If you need historical data, use the CDR query interface in the VOS3000 client to export it manually, as described in our CDR analysis guide.

Step 2: Configure Non-Connected Call Recording ๐Ÿ“ž

  1. ๐Ÿ“‹ In the same Softswitch parameter section, locate SS_CDR_RECORD_NONCONNECT
  2. โœ๏ธ Change the value from Off to On if you need zero-duration call records in the export
  3. ๐Ÿ’พ Save the configuration

๐Ÿ’ก Recommendation: Enable SS_CDR_RECORD_NONCONNECT for most deployments. The additional disk space consumed by zero-duration CDRs is minimal compared to the operational value they provide. However, during a DDoS or flood attack, the volume of zero-duration CDRs can spike dramatically. If disk space is a concern during such events, you can temporarily disable this parameter to prevent disk overflow.

Step 3: Configure File Rotation Parameters ๐Ÿ”„

  1. ๐Ÿ“‹ Navigate: Operation management โ†’ Server management โ†’ Server parameter
  2. ๐Ÿ” Review SERVER_CDR_FILE_WRITE_INTERVAL โ€” set the hourly interval for new file creation (default: one file per hour)
  3. ๐Ÿ” Review SERVER_CDR_FILE_WRITE_MAX โ€” set the maximum number of CDR files to retain (default: 2048)
  4. ๐Ÿ’พ Save and restart the VOS3000 service for changes to take effect
ScenarioWRITE_INTERVALWRITE_MAXResult
โœ… Default (most deployments)3600 (1 hour)2048~85 days of CDR files retained
๐Ÿ“Š High-traffic analytics1800 (30 min)4096~85 days with finer granularity
๐Ÿ’พ Low disk space3600 (1 hour)720~30 days of retention
๐Ÿ›ก๏ธ Long-term compliance3600 (1 hour)4096~170 days of retention

๐Ÿ›ก๏ธ Another important softswitch parameter that affects CDR text file content is SS_CDR_RECORD_ILLEGAL. This parameter controls whether CDRs are generated for calls originating from unauthorized IP addresses โ€” calls that VOS3000 rejects as illegal or unauthorized.

AttributeValue
๐Ÿ“Œ Parameter NameSS_CDR_RECORD_ILLEGAL
๐Ÿ”ข Default ValueOn
๐Ÿ“ DescriptionRecord illegal call (per VOS3000 manual ยง4.3.5.1, page 225)

๐Ÿ”’ Unlike SS_CDR_RECORD_NONCONNECT (which defaults to Off), SS_CDR_RECORD_ILLEGAL defaults to On. This means VOS3000 is configured by default to record CDRs for hack attempts and unauthorized call attempts. These records appear in the text file export with a special billing mode code of -1 (no billing), making them easy to filter and analyze separately. For more details on how VOS3000 handles unauthorized calls, see our guide on illegal call detection and prevention.

๐Ÿ› ๏ธ Parsing VOS3000 CDR Text Files for External Systems

๐Ÿ“Š Once the VOS3000 CDR text file export is configured, the next step is integrating the exported data with your external systems. The pipe-delimited format is universally supported by programming languages, databases, and analytics tools.

๐Ÿ“‹ Parsing Methods Comparison

MethodBest ForComplexityReal-Time
๐Ÿ Python scriptCustom analytics, billing importMediumNear-real-time (cron)
๐Ÿ—„๏ธ MySQL LOAD DATADatabase import, reportingLowBatch (hourly)
๐Ÿ“Š Excel/CSV conversionManual review, one-time analysisLowManual
๐Ÿ”„ Logstash/FluentdElasticsearch, SIEM integrationHighNear-real-time

๐Ÿ“‹ Python Parsing Example

import csv

# VOS3000 CDR field names (per manual ยง4.4)
CDR_FIELDS = [
    'callerE164', 'calleeE164', 'startTime', 'stopTime',
    'holdTime', 'endReason', 'endDirection',
    'callerGatewayId', 'calleeGatewayId',
    'callerIp', 'calleeIp',
    'callerAccessE164', 'calleeAccessE164',
    'callerToGatewayE164', 'calleeToGatewayE164',
    'calleeBilling', 'billingMode',
    'callerPdd', 'calleePdd'
]

def parse_cdr_file(filepath):
    """Parse VOS3000 CDR text file into list of dictionaries."""
    records = []
    with open(filepath, 'r') as f:
        reader = csv.reader(f, delimiter='|')
        for row in reader:
            if len(row) >= 17:  # Minimum core fields
                record = dict(zip(CDR_FIELDS[:len(row)], row))
                records.append(record)
    return records

# Usage: Parse a CDR file and filter connected calls
cdr_data = parse_cdr_file('/home/vos3000/cdr/2026042612.txt')
connected = [r for r in cdr_data if int(r.get('holdTime', 0)) > 0]
print(f"Total CDRs: {len(cdr_data)}, Connected: {len(connected)}")

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

โš ๏ธ Misconfigurations and misunderstandings about the CDR text file export can lead to data loss, disk space issues, or incomplete records. Here are the most common problems and their solutions:

โŒ Problem 1: No CDR Text Files Being Generated

๐Ÿ” Symptom: The cdr/ directory is empty or does not contain the expected hourly text files.

๐Ÿ’ก Cause: SS_CDR_RECORD_TO_FILE is still set to Off (the default value). Many operators assume CDR files are generated automatically, but this feature must be explicitly enabled.

โœ… Solution:

  • ๐Ÿ”ง Navigate to Softswitch parameter and set SS_CDR_RECORD_TO_FILE = On
  • ๐Ÿ’พ Save the configuration and wait for the next hourly interval
  • ๐Ÿ“ Verify the cdr/ directory exists and has proper write permissions
  • ๐Ÿ“‹ Confirm with the VOS3000 system parameter guide that no other settings are blocking file creation

โŒ Problem 2: Missing Zero-Duration Call Records

๐Ÿ” Symptom: The CDR text files only contain records for connected calls. Failed calls, busy signals, and no-answer attempts are absent.

๐Ÿ’ก Cause: SS_CDR_RECORD_NONCONNECT is set to Off (default), which excludes zero-duration calls from the text file export.

โœ… Solution:

  • ๐Ÿ“ž Set SS_CDR_RECORD_NONCONNECT = On in Softswitch parameter
  • ๐Ÿ“Š Be aware this increases file sizes โ€” monitor disk usage after enabling
  • ๐Ÿ” For fraud detection purposes, this setting is strongly recommended

โŒ Problem 3: Disk Space Exhaustion from CDR Files

๐Ÿ” Symptom: The server runs low on disk space, and the cdr/ directory contains thousands of large CDR text files.

๐Ÿ’ก Cause: SERVER_CDR_FILE_WRITE_MAX is set too high, or an external script is not archiving and cleaning up old CDR files.

โœ… Solution:

  • ๐Ÿ”„ Reduce SERVER_CDR_FILE_WRITE_MAX to a lower value (e.g., 720 for ~30 days)
  • ๐Ÿ“ Implement a cron job to move CDR files older than X days to archive storage
  • ๐Ÿ“Š Monitor disk usage with the VOS3000 disk alarm feature
  • ๐Ÿ’พ Consider compressing older CDR files with gzip to save space

โŒ Problem 4: Parsing Errors Due to Extra Pipe Characters

๐Ÿ” Symptom: External parsing scripts produce incorrect field alignment or data corruption.

๐Ÿ’ก Cause: Caller or callee E164 fields contain unexpected characters, or the number of pipe separators varies between CDR records.

โœ… Solution:

  • ๐Ÿ”ง Use a robust parser that handles variable field counts gracefully
  • ๐Ÿ“‹ Always validate the number of fields per line before processing
  • ๐Ÿ“Š Reference the official VOS3000 manual ยง4.4 (page 241) for the exact field specification

๐Ÿ’ก VOS3000 CDR Text File Export Best Practices

๐ŸŽฏ Follow these best practices to get the most from your VOS3000 CDR text file export configuration:

Best PracticeRecommendationReason
๐Ÿ“ Always enable SS_CDR_RECORD_TO_FILESet to Onโœ… Provides file-based CDR backup independent of MySQL
๐Ÿ“ž Enable SS_CDR_RECORD_NONCONNECTSet to On for most deployments๐Ÿ” Captures failed call data for fraud detection and quality analysis
๐Ÿ”„ Archive CDR files regularlyMove files older than 30 days to archive๐Ÿ’พ Prevents disk space exhaustion on active server
๐Ÿ“Š Validate CDR data dailyCheck record counts and file sizes๐Ÿ›ก๏ธ Early detection of data export problems
๐Ÿ”’ Set proper file permissionsRestrict cdr/ directory access๐Ÿ” CDR files contain sensitive call data and IP addresses
๐Ÿ“ก Consider real-time forwardingUse SERVER_CDR_REAL_TIME_REPORT_SERVERโšก For immediate CDR delivery to external billing systems

๐Ÿ’ก Pro tip: The VOS3000 CDR text file export works best as part of a comprehensive data strategy. Combine the text file export with the VOS3000 billing system for complete revenue tracking, and use the exported data to build custom dashboards that go beyond what the VOS3000 client interface provides. For operators who need real-time CDR delivery rather than hourly file batches, the SERVER_CDR_REAL_TIME_REPORT_SERVER parameter provides an alternative integration path.

๐Ÿ“Š Complete VOS3000 CDR Export Parameter Reference

๐Ÿ“‹ Here is the complete reference table for all parameters related to CDR text file export, sourced from the official VOS3000 2.1.8.0/2.1.9.07 English manual:

ParameterDefaultCategoryPurpose
SS_CDR_RECORD_TO_FILEOffSoftswitchEnable CDR text file export
SS_CDR_RECORD_NONCONNECTOffSoftswitchInclude zero-duration calls in export
SS_CDR_RECORD_ILLEGALOnSoftswitchRecord illegal/unauthorized call CDRs
SERVER_CDR_FILE_WRITE_INTERVALNoneServerCDR file creation interval (60โ€“86400 seconds)
SERVER_CDR_FILE_WRITE_MAX2048ServerMaximum CDR files retained (10โ€“4096)
SERVER_CDR_REAL_TIME_REPORT_SERVER(blank)ServerReal-time CDR forwarding server address
SERVER_QUERY_CDR_DENY_TIME(blank)ServerNo CDR query time (blackout hours)
SERVER_QUERY_CDR_MAX_DAY_INTERVAL31ServerMaximum CDR query date range (days)
SERVER_MAX_CDR_PENDING_LIST_LENGTH100000ServerCDR queue length limit (10000โ€“100000)

โ“ Frequently Asked Questions

โ“ How do I enable VOS3000 CDR text file export?

๐Ÿ“ To enable the VOS3000 CDR text file export, navigate to Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter and set SS_CDR_RECORD_TO_FILE to On. This parameter is Off by default, so it must be explicitly enabled. After saving the configuration, VOS3000 will begin creating hourly CDR text files in the cdr/ directory starting from the next hourly interval. The files follow the naming convention YYYYMMDDHH.txt as documented in the VOS3000 manual ยง4.4.

โ“ What is the difference between SS_CDR_RECORD_TO_FILE and SS_CDR_RECORD_NONCONNECT?

๐Ÿ”ง SS_CDR_RECORD_TO_FILE is the master switch that enables CDR text file export entirely. Without it set to On, no CDR text files are created at all. SS_CDR_RECORD_NONCONNECT only takes effect when SS_CDR_RECORD_TO_FILE is already On โ€” it controls whether zero-duration call records (failed calls, busy signals, no-answer attempts) are included in the exported text files. When SS_CDR_RECORD_NONCONNECT is Off, only connected calls with non-zero hold time appear in the export.

โ“ Where are VOS3000 CDR text files stored?

๐Ÿ“‚ VOS3000 CDR text files are stored in the cdr/ directory under the VOS3000 installation path. Each file is named using the format YYYYMMDDHH.txt, where each file contains all CDRs for calls that ended during that specific hour. For example, the file 2026042612.txt contains all CDRs for calls that ended between 12:00:00 and 12:59:59 on April 26, 2026. This file structure is documented in the official VOS3000 manual ยง4.4 (page 241).

โ“ Can I export historical CDR data that was generated before enabling text file export?

๐Ÿ“‹ No, the VOS3000 CDR text file export only generates files for new calls after the feature is enabled. Historical CDR data that was generated while SS_CDR_RECORD_TO_FILE was Off is only available through the VOS3000 client CDR query interface or by querying the MySQL database directly. If you need to export historical data, use the CDR query function in the client and export the results manually. This is why it is strongly recommended to enable SS_CDR_RECORD_TO_FILE from the very first day of deployment.

โ“ How much disk space do VOS3000 CDR text files consume?

๐Ÿ’พ Disk space consumption depends entirely on your call volume. Each CDR record is approximately 200โ€“350 bytes in the pipe-delimited text format. A system processing 100,000 calls per day would generate roughly 25โ€“35 MB of CDR text data per day, or about 1 GB per month. With the default SERVER_CDR_FILE_WRITE_MAX of 2048 files (roughly 85 days of retention), a mid-traffic system would need approximately 3โ€“4 GB of dedicated disk space for CDR files. Always monitor disk usage and configure VOS3000 disk alarms to receive alerts before space runs out.

โ“ What is the pipe delimiter character used in VOS3000 CDR text files?

๐Ÿ”— The VOS3000 CDR text file format uses the vertical bar or pipe character (|, ASCII 124) as the field delimiter. Each line in the file represents one call detail record, with fields separated by pipe characters. This format is widely supported by data processing tools, programming languages (Python, PHP, Perl), database import utilities (MySQL LOAD DATA INFILE), and spreadsheet applications. When parsing, always split on the pipe character and validate the expected field count.

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

๐Ÿ”ง Proper VOS3000 CDR text file export configuration ensures your billing data is complete, your audit trail is intact, and your external systems receive the call data they need. Whether you are setting up CDR export for the first time, troubleshooting missing records, or integrating CDR data with an external billing platform, expert guidance saves time and prevents costly data gaps. ๐Ÿ“Š

๐Ÿ’ฌ WhatsApp: +8801911119966 โ€” Get immediate assistance with VOS3000 CDR text file export setup, parsing, and integration. Our team specializes in VOS3000 softswitch configuration, billing system integration, and custom CDR analytics solutions. ๐Ÿ”ง

๐Ÿ”— Learn more about related VOS3000 CDR and billing configurations:


๐Ÿ“ž 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