How i receive call data records in Central Server

[chi.dinh]

Follow the https://www.3cx.com/docs/cdr-call-data-records/:
"3CX CDR can send call data records to a CDR Central server. In this mode, 3CX CDR Service will act as a client and you need to provide the IP Address and TCP Port of the CDR Server that is handling your CDR Requirements."
I opened port 5015 on ServerA (Linux Central Server), but I do not know what things i need do more on ServerA then ServerA could receive call data records from 3cx pbx. Also, what is "call data records" which 3cx pbx send to ServerA? It is file or others? I just tcpdump on ServerA and see every call i made then 3cx pbx send 4 TCP packet to ServerA via 5015, but these packet not have any information relate to the calls.

Please share me some particular information how and what i must do in ServerA then could receive "call data record"? And explain for me some above posted.

Thank you very much.

 

[VoIPTools]

"3CX CDR can send call data records to a CDR Central server. In this mode, 3CX CDR Service will act as a client and you need to provide the IP Address and TCP Port of the CDR Server that is handling your CDR Requirements."

This requires you to write a TCP Socket client that subscribes to the TCP Socket server hosted by the 3CX server.

It is my personal opinion that using a socket connection is the wrong way to handle getting CDR unless you have no other choice. This service was originally created (I believe) to allow legacy Hotel management systems to track calls made by guests. These legacy systems typically can only utilize a socket connection.

If you are building a solution from scratch, I would configure 3CX to create individual CDR files for each call, and then process (parse) these files to get call detail information. The socket approach has one significant problem -- if your service goes down you lose all the records that were generated while the service was down. Further, from my perspective, it's a lot harder to create a resilient socket connection than it is to read and parse a CSV file.

I opened port 5015 on ServerA (Linux Central Server), but I do not know what things i need do more on ServerA then ServerA could receive call data records from 3cx pbx.

Since the central server is a "client" to the 3CX server(s) the port needs to be opened on the 3CX server, not the central server. Remember, this is where you install your socket "client" service that you wrote.

Also, what is "call data records" which 3cx pbx send to ServerA? It is file or others? I just tcpdump on ServerA and see every call i made then 3cx pbx send 4 TCP packet to ServerA via 5015, but these packet not have any information relate to the calls.

You will not receive a file, you will receive data packets.

Alternatives:

You make an important point when you mention your 3CX server is on Linux. This highlights one of the challenges of processing the CDR files (vs a socket connection). You need to somehow get access to the files so they can be processed. You could, for example, create an FTP client that pulls the files from the 3CX server to the service that reads and parses the data.

We handled this challenge by writing a small Relay application that monitors for new CDR files. When a file is created, we automatically parse the file and send this data as an event to our client application (3CX Exporter) which then saves the data in a SQL database.

If the client application is down for a period of time, when the client starts up it automatically queries the relay for any unprocessed files and handles them right away. This approach means you never miss any CDR because it can always catch up after an outage.

One thing to keep in mind when processing CDR transactions. You did not mention what you wanted the CDR data for. This data is created AFTER the call is disconnected, so it is not technically real-time data. If you need to notified when a call starts, rather than when the call ends, you will need to subscribe to events generated by the 3CX Call Control API.

 

[chi.dinh]

Hi Mr. voiptoys. Thank you so much for your advice.