How to Read CDR Info: Fields, Formats, and Troubleshooting

How to Read CDR Info: Fields, Formats, and TroubleshootingCall Detail Records (CDRs) are structured logs generated by telecommunication systems that record information about telephone calls, SMS messages, and other communication sessions. Whether you work in telecom operations, network engineering, fraud detection, billing, or data analytics, being able to read and interpret CDR info is a fundamental skill. This article explains common CDR fields, popular formats, parsing techniques, and troubleshooting steps to help you extract useful insights and resolve issues efficiently.

What is a CDR?

A Call Detail Record (CDR) captures metadata about a communication event. Unlike call audio, CDRs do not contain the actual content of the conversation; instead, they include attributes that describe who communicated, when, how long, and how the session was routed and billed. Typical uses include billing, traffic analysis, capacity planning, regulatory reporting, and security investigations.

Common CDR Fields

Below are typical fields you’ll encounter in CDRs. Field names can vary by vendor (e.g., Ericsson, Huawei, Cisco, Asterisk, Freeswitch, Kamailio), but the concepts are consistent.

• Record ID / Unique ID: A unique identifier for the CDR.
• Timestamp / Start Time: When the call/session began (often in UTC).
• End Time / Stop Time: When the call/session ended.
• Duration: Total duration of the call/session (seconds or hh:mm:ss).
• Calling Number / A-Party: The originator’s phone number or identifier.
• Called Number / B-Party: The destination phone number or identifier.
• Called Station / Destination: Location or endpoint of the called party.
• Calling Party Presentation: Whether caller ID was shown or restricted.
• Disposition / Call Result / Cause Code: Outcome of the call (e.g., ANSWERED, NO ANSWER, BUSY, REJECTED) and standardized cause codes (SIP/ISDN cause).
• Call Type / Service Type: Voice, SMS, MMS, data session, voicemail, etc.
• Media/Codec: Codec used (e.g., G.711, G.729) for voice streams.
• Caller Location / Cell ID / eNodeB / TAC: Radio network identifiers for mobile calls.
• Route / Trunk / Outgoing Gateway: The network path or trunk used to complete the call.
• Billing Info / Rate / Charge: Tariff applied and cost metrics.
• Charging Party / Account ID / IMSI / IMEI: Subscriber identifiers used for billing and tracking.
• Sequence Number: Order number for batching and reassembly.
• Call Direction: Inbound, outbound, or internal.
• SIP Fields (for VoIP CDRs): From, To, Call-ID, CSeq, Via, User-Agent, etc.
• Tags / Metadata / Custom Fields: Vendor-specific or operator-specific additional data.

Common Formats

CDRs come in several representations. Knowing how to recognize and parse each format is essential.

• CSV / Flat File: A common, human-readable format where fields are comma-separated. Easy to import into spreadsheets or ETL tools.
• Fixed-width Text: Each field occupies a fixed number of characters. Parsing requires a field map.
• XML: Hierarchical and self-descriptive; often used in OSS/BSS integrations.
• JSON: Increasingly common for REST APIs and modern logging systems.
• Binary / Proprietary: Some systems store compact binary records; vendor-specific parsers are required.
• SQL DB Entries: CDRs may be stored directly in relational tables for fast querying.
• CDR Utilities Export: Telecom switches often provide export utilities producing vendor-specific formats (e.g., Asterisk CDR, Ericsson CDR).

How to Read CDRs: Step-by-Step

1. Identify the format and encoding (CSV, XML, JSON, binary, DB). Verify character set (UTF-8, ISO-8859-1).
2. Map fields: Obtain the vendor’s field dictionary or header row. If none, infer fields by sampling records.
3. Normalize timestamps to a common timezone (usually UTC) and standard format (ISO 8601).
4. Convert durations and byte counts into human-friendly units (seconds, hh:mm:ss, MB).
5. Match identifiers: correlate IMSI/IMEI with subscriber databases; tie trunk names to network diagrams.
6. Interpret disposition codes: map SIP/ISDN cause codes to human-readable outcomes.
7. Validate billing fields: compare applied rates and computed charges against tariff tables.
8. Aggregate for analysis: group by caller, called number, trunk, geography, or time windows.
9. Visualize: use charts for traffic trends, top callers, peak hours, anomalous spikes.

Parsing Examples

CSV example:

record_id,start_time,end_time,calling_number,called_number,duration,disposition,call_type 12345,2025-08-30T14:02:10Z,2025-08-30T14:07:42Z,+15551234567,+15557654321,332,ANSWERED,VOICE 

XML example:

<cdr>   <recordId>12345</recordId>   <startTime>2025-08-30T14:02:10Z</startTime>   <endTime>2025-08-30T14:07:42Z</endTime>   <callingNumber>+15551234567</callingNumber>   <calledNumber>+15557654321</calledNumber>   <duration>332</duration>   <disposition>ANSWERED</disposition>   <callType>VOICE</callType> </cdr> 

Quick Python snippet (CSV -> dict):

import csv from datetime import datetime with open('cdrs.csv', newline='') as f:     reader = csv.DictReader(f)     for row in reader:         start = datetime.fromisoformat(row['start_time'].replace('Z', '+00:00'))         duration = int(row['duration'])         print(row['record_id'], start, duration, row['calling_number'], row['disposition']) 

Troubleshooting CDR Issues

Common problems and how to approach them:

• Missing fields: Check export configuration; confirm firmware/software versions; consult field dictionary.
• Incorrect timestamps: Verify timezone settings on network elements and CDR export tools; look for clock drift or NTP issues.
• Duplicate records: Identify sequence numbers and unique IDs; check retries or replication processes.
• Mismatched durations: Compare start/end timestamps; inspect intermediate events (transfers, on-hold).
• Unexpected dispositions: Cross-reference SIP/ISDN cause codes and SIP logs; check for network issues (SIP ⁄₄₈₆, ISDN 31x codes).
• Data truncation / encoding errors: Confirm field lengths and character encodings; look for special characters in metadata.
• Billing discrepancies: Recalculate charges from duration and rates; validate rounding rules and rating windows.
• High-volume parsing failures: Use streaming parsers, tune memory limits, batch-processing pipelines, and parallel workers.

Tools and Utilities

• Command-line: awk, sed, grep, cut for simple transformations.
• Scripting: Python (pandas), Perl, Ruby for flexible parsing and ETL.
• Databases: PostgreSQL, ClickHouse for high-volume storage and fast queries.
• OSS/BSS Tools: Honor vendor-specific tools for ingestion and reconciliation.
• Log processors: Logstash, Fluentd, Kafka for streaming ingestion.
• Visualization: Grafana, Kibana, Tableau for dashboards.

Best Practices

• Standardize CDR formats internally — transform vendor-specific fields into a canonical schema.
• Keep clocks synchronized (NTP) across all network elements.
• Store raw CDR files for auditability and reprocessing.
• Implement data retention and anonymization policies for privacy compliance.
• Validate CDRs during ingestion with schema checks and sanity rules (e.g., duration >= 0).
• Monitor parsing pipelines and set alerts for spikes in errors or duplicates.

Example Use Cases

• Billing: Generate invoices by rating each CDR according to applied tariffs.
• Fraud detection: Spot abnormal call patterns (high-frequency short calls, unusual destinations).
• Network troubleshooting: Trace call failures and route performance issues using cause codes and trunk metrics.
• Capacity planning: Analyze traffic volumes by time-of-day and trunk utilization.
• Regulatory reporting: Produce legally required call logs and interception reports when mandated.

Conclusion

Reading CDR info requires understanding the fields, recognizing the format, and applying systematic parsing and validation steps. With the right tools and best practices—field mapping, timestamp normalization, and robust ingestion pipelines—you can extract accurate billing data, diagnose network issues, and derive business insights from CDRs. If you have a sample CDR file or a specific vendor format, share it and I can provide a tailored parsing script or schema mapping.