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. 🔧

🔐 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 🔔

Attribute	Value
📌 Field Position	1 (first field)
📐 Data Type	String (numeric E.164 format)
📝 Description	The caller ID — the originating party’s phone number
🔢 Example	12125551234
⚠️ Notes	May 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 📞

Attribute	Value
📌 Field Position	2
📐 Data Type	String (numeric E.164 format)
📝 Description	The callee ID — the destination phone number
🔢 Example	18005559876
⚠️ Notes	This 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 ⏰

Attribute	Value
📌 Field Position	3
📐 Data Type	Datetime string
📝 Description	Begin time of the call
🔢 Example	2018-12-20 11:20:18
⚠️ Notes	Format 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 🛑

Attribute	Value
📌 Field Position	4
📐 Data Type	Datetime string
📝 Description	End time of the call
🔢 Example	2018-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 ⏱️

Attribute	Value
📌 Field Position	5
📐 Data Type	Integer (milliseconds)
📝 Description	Call duration in milliseconds
🔢 Example	45000 (equals 45 seconds)
🚨 Critical Note	Value 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 📋

Attribute	Value
📌 Field Position	6
📐 Data Type	String/Integer
📝 Description	End reason — SIP response code or Q.850 cause code
🔢 Example	200 (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 🔄

Attribute	Value
📌 Field Position	7
📐 Data Type	Integer (0, 1, or 2)
📝 Description	Hangup 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 📡

Field	Position	Description	Example
callerGatewayId	8	Calling gateway ID	1001
calleeGatewayId	9	Called gateway ID	2003

📡 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 🌐

Field	Position	Description	Example
callerIp	10	Caller IP address	192.168.1.100
calleeIp	11	Callee IP address	10.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 📥

Field	Position	Description
callerAccessE164	12	Incoming caller — the original caller ID as received by VOS3000 before any transformations
calleeAccessE164	13	Incoming 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 📤

Field	Position	Header Name	Description
callerToGatewayE164	14	callerToGatewayE164	Outbound caller — the caller ID sent to the outgoing gateway
calleeToGatewayE164	15	calleeToGatewayE164	Outbound 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 💰

Attribute	Value
📌 Field Position	16
📐 Data Type	Integer (0 or 1)
📝 Description	Billing 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 💳

Attribute	Value
📌 Field Position	17
📐 Data Type	Integer (-1, 0, 1, or 3)
📝 Description	Charge 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 ⏱️

Field	Position	Description
callerPdd	18	Time elapsed from call received to call connected (incoming PDD)
calleePdd	19	Time 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 Name	Type	Description	Example
1	callerE164	String	The caller ID	12125551234
2	calleeE164	String	The callee ID	18005559876
3	startTime	Datetime	Call begin time	2018-12-20 11:20:18
4	stopTime	Datetime	Call end time	2018-12-20 16:34:09
5	holdTime	Integer (ms)	Call duration in milliseconds	45000
6	endReason	String/Int	End reason code	200
7	endDirection	Integer	Hangup side (0/1/2)	0
8	callerGatewayId	Integer	Calling gateway	1001
9	calleeGatewayId	Integer	Called gateway	2003
10	callerIp	String	Caller IP address	192.168.1.100
11	calleeIp	String	Callee IP address	10.0.0.50
12	callerAccessE164	String	Incoming caller	12125551234
13	calleeAccessE164	String	Incoming callee	01118005559876
14	callerToGatewayE164	String	Outbound caller	12125551234
15	calleeToGatewayE164	String	Outbound callee	18005559876
16	calleeBilling	Integer	Billing method (0/1)	0
17	billingMode	Integer	Charge mode (-1/0/1/3)	0
18	callerPdd	Integer	Incoming PDD (ms)	3200
19	calleePdd	Integer	Outgoing 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 Field	MySQL Column	Common Billing Label	Transform Needed
callerE164	VARCHAR(32)	ANI / Calling Number	None
calleeE164	VARCHAR(32)	DNIS / Called Number	None
startTime	DATETIME	Call Start / Setup Time	Parse datetime string
holdTime	INT	Duration (seconds)	⚠️ Divide by 1000
endReason	VARCHAR(16)	Release Cause	Map to cause code table
endDirection	TINYINT	Release Source	Map 0/1/2 to labels
billingMode	TINYINT	Billing Type	Map -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:

• VOS3000 CDR Analysis and Billing — Complete guide to analyzing CDR data for revenue optimization
• VOS3000 CDR Billing Discrepancy — Troubleshooting billing differences between CDR and rate tables
• VOS3000 Billing System — Overview of the entire VOS3000 billing architecture
• VOS3000 Call Termination Reasons — Complete reference for endReason codes in CDR records
• VOS3000 Parameter Description — Complete parameter reference for all VOS3000 configuration settings
• VOS3000 Gateway Configuration — Setting up mapping and routing gateways for CDR field population

---

📞 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

---