According to the manual:
Configuring CDR to output to a socket in passive mode requires you to configure a port which is free on the 3CX Phone System Server. In this mode, 3CX CDR Service will act as a Server and will expect a CDR Client to connect to the IP
ort configured. This implies that you must allow data traffic to pass from your firewall in TCP Mode.
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.
The centralized CDR Server is a new feature (to me) that I have never tried. But if this works the way the old socket connection did, if the socket goes down (internet, network, or application issue), you will miss some transactions. Maybe for your application, that's not the end of the world, but in many scenarios, it can be an important consideration. To utilize this 3CX feature, you would need to write a service application that makes a resilient socket connection to handle the events. That's not all that straightforward.
As others have suggested, you could write (or perhaps purchase an existing application) that could connect remotely and periodically downloads the files, but you were looking for as close to real-time as possible. With this approach, you would need to constantly poke the 3CX server.
Another alternative would be to write a relay application that resides on the 3CX server and subscribes to the 3CX Call Control API to get real-time events, but that's a huge undertaking.
Alternatively, you could use our VoIPTools API to subscribe to CDR events. We have a CDR event that provides the contents of the new CDR file as a json object. These events are real-time (as soon as the file is created), but remember the files are not created until the call is ended. If you want actual real-time events when the call is started (rather than waiting for the call to end) you can subscribe to the actual 3CX events using our API.
I should point out that we also support the old-school approach for getting a list of files, downloading individual files, renaming files, and deleting files -- essentially recreating what you did when your PBX was on-prem.
Lastly, we have an Exporter tool that can automate the whole process of subscribing to the real-time CDR events, parsing the files, and placing the data right into a database. You wouldn't have to do anything, it would just happen. Exporter can even catch up if you have a temporary outage that interrupts the real-time events so you never miss a transaction.
From my perspective, it's certainly possible to build tools to recreate what you did previously when your server was on-prem, but every alternative requires a degree of effort to automate. If you don't want to build a solution yourself, we have tools that automated the entire process for you.
