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 ContentsVOS3000 CDR Pipe Format Definitive 18-Field Reference Guide VOS3000 CDR Pipe Format Overview CDR Line Format Structure Complete Field-by-Field Reference – VOS3000 CDR PipeField 1: callerE164 — The Caller ID Field 2: calleeE164 — The Callee ID Field 3: startTime — Call Begin Time Field 4: stopTime — Call End Time Field 5: holdTime — Call Duration Field 6: endReason — End Reason Code Field 7: endDirection — Hangup Side Fields 8–9: Gateway Identifiers Fields 10–11: IP Addresses Fields 12–13: Access (Incoming) E164 Numbers Fields 14–15: Outbound (To Gateway) E164 Numbers Field 16: calleeBilling — Billing Method Field 17: billingMode — Charge Mode Fields 18–19: Post-Dial Delay Metrics Complete VOS3000 CDR Pipe Format Quick Reference Table External System Mapping Guide – VOS3000 CDR Pipe Frequently Asked Questions How many fields are in the VOS3000 CDR pipe format? Why is holdTime in milliseconds instead of seconds? What is the difference between callerE164 and callerAccessE164? What does a billingMode of -1 mean in the CDR? How do I parse VOS3000 CDR files with different field counts? Are VOS3000 CDR timestamps in UTC or local time? Need Expert Help with VOS3000 CDR Pipe Format? Need Professional VOS3000 Setup Support?

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

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

FieldPositionDescriptionExamplecallerGatewayId8Calling gateway ID1001calleeGatewayId9Called 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

FieldPositionDescriptionExamplecallerIp10Caller IP address192.168.1.100calleeIp11Callee 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

FieldPositionDescriptioncallerAccessE16412Incoming caller — the original caller ID as received by VOS3000 before any transformationscalleeAccessE16413Incoming 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 NameDescriptioncallerToGatewayE16414callerToGatewayE164Outbound caller — the caller ID sent to the outgoing gatewaycalleeToGatewayE16415calleeToGatewayE164Outbound 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

FieldPositionDescriptioncallerPdd18Time 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 NameTypeDescriptionExample1callerE164StringThe caller ID121255512342calleeE164StringThe callee ID180055598763startTimeDatetimeCall begin time2018-12-20 11:20:184stopTimeDatetimeCall end time2018-12-20 16:34:095holdTimeInteger (ms)Call duration in milliseconds450006endReasonString/IntEnd reason code2007endDirectionIntegerHangup side (0/1/2)08callerGatewayIdIntegerCalling gateway10019calleeGatewayIdIntegerCalled gateway200310callerIpStringCaller IP address192.168.1.10011calleeIpStringCallee IP address10.0.0.5012callerAccessE164StringIncoming caller1212555123413calleeAccessE164StringIncoming callee0111800555987614callerToGatewayE164StringOutbound caller1212555123415calleeToGatewayE164StringOutbound callee1800555987616calleeBillingIntegerBilling method (0/1)017billingModeIntegerCharge mode (-1/0/1/3)018callerPddIntegerIncoming PDD (ms)320019calleePddIntegerOutgoing 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 NeededcallerE164VARCHAR(32)ANI / Calling NumberNonecalleeE164VARCHAR(32)DNIS / Called NumberNonestartTimeDATETIMECall Start / Setup TimeParse datetime stringholdTimeINTDuration (seconds) Divide by 1000endReasonVARCHAR(16)Release CauseMap to cause code tableendDirectionTINYINTRelease SourceMap 0/1/2 to labelsbillingModeTINYINTBilling 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:

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