3CX VoIP Call Detail Records In Graylog

Even with the rise of high-speed networks and sophisticated monitoring tools, VoIP Call Data Records (CDR) remain an essential resource for troubleshooting and optimizing bandwidth usage. These records provide a granular view of call quality, latency, jitter, and packet loss—critical factors that directly impact voice performance. While real-time monitoring solutions can detect immediate issues, CDRs offer historical insights that help IT teams pinpoint recurring problems, track trends, and ensure networks are properly provisioned. Whether diagnosing call degradation, planning capacity upgrades, or investigating security anomalies, CDR are still one of the most reliable tools for keeping VoIP systems running smoothly.

In this blog, we cover the 3CX VoIP PBX and the call data records that are sent to Graylog.

Configuring 3CX for CDR Logging

To do this in the 3CX call server, you configure a 3CX CDR service as a client, as an active socket, to an IP address on a specific port. What happens inside there is that the logs will be shipped in a comma-delimited format, with the fields you see in their field list.

The field list contains a lot of records. You can choose to eliminate or add the ones you want, but make sure you keep the order the same, because when you start parsing the data, the order is crucial.

Field Definitions

If you go to the 3CX website under the CDR records section, you’ll find the definition of all the different types of fields, which will help you understand what the data contains.

Creating a 3CX CDR Input in Graylog

In Graylog, create a 3CX CDR input, which is simply a plain text TCP connection to port 3000.

Grok Pattern for Parsing

Here is a grok pattern called: 3CX_CDR. This pattern follows the order of the fields that appear inside the PBX system. Note, this pattern is tied to the image below for the order of the fields. Modifying the fields in 3CX will require changes to this pattern.

%{NUMBER:history_id},(?<call_id>[^,]*),%{TIME:duration},%{TIMESTAMP_ISO8601:time_start},%{TIMESTAMP_ISO8601:time_answered},%{TIMESTAMP_ISO8601:time_end},%{WORD:reason_terminated},(?<from_no>[^,]*),(?<to_no>[^,]*),(?<from_dn>[^,]*),(?<to_dn>[^,]*),(?<dial_no>[^,]*),(?<reason_changed>[^,]*),(?<final_number>[^,]*),(?<final_dn>[^,]*),(?<bill_code>[^,]*),(?<bill_rate>[^,]*),(?<bill_cost>[^,]*),(?<bill_name>[^,]*),(?<chain>[^,]*),(?<from_type>[^,]*),(?<to_type>[^,]*),(?<final_type>[^,]*),(?<from_dispname>[^,]*),(?<to_dispname>[^,]*),(?<final_dispname>[^,]*),(?<missed_queue_calls>[^,]*)

Fields available in order within the PBX System based on this grok pattern:

The Parsing Rule:

rule "Parse 3CX CDR GROK"
When
   true
       //Route 3CX CDR to Stream old:
then
    let grokp = grok(
        pattern:"%{3CX_CDR}",
        value:to_string($message.message),
        only_named_captures: true
        );
        
    set_fields(grokp);
    set_field("grok_parse",true);
end

It’s important that you don’t reorder these fields unless you also go into Graylog and reorder your grok pattern accordingly. Inside the rule, I’ve referenced the pattern so that when the data comes in, it automatically parses out the records.

Additional Parsing of the Timestamp.

rule "Parse - 3cx - End Call TimeStamp Breakout"
When
    $message.grok_parse == true
then
    let grokp = grok(
        pattern:"%{TIMESTAMP_ISO8601}",
        value:to_string($message.time_end),
        only_named_captures: false
        );
        
    set_fields(fields:grokp,prefix:"TimeEnd_");
    set_field("grok_parse_timeend_timestamp",true);
    remove_field("TimeEnd_TIMESTAMP_ISO8601");
    remove_field("TimeEnd_MINUTE");
    remove_field("TimeEnd_SECOND");
end

Graylog for Telecom

VoIP Call Data Records (CDRs) may not be the flashiest tool in a network administrator’s arsenal, but they remain one of the most reliable. From diagnosing call quality issues to optimizing bandwidth on your network and uncovering security threats, CDR provide the historical insights needed to keep VoIP systems running smoothly. While real-time monitoring has its place, a solid understanding of CDR data ensures that recurring problems don’t go unnoticed and that networks are properly scaled for future demand. In short, if you’re not leveraging CDR in your VoIP troubleshooting process, you’re missing a critical piece of the puzzle. Try Graylog and and get those VoIP logs and watch this Video!

See the next blog on the 3CX attack detected by Graylog here called “Detecting the 3CX Supply Chain Attack with Graylog and Sigma Rules“