Erro|CHR: [CDR] failed to open CDR output [email protected]:3000

[chi.dinh]

Please help me!
3cxSystemService.log write:
2020/04/10 16:53:55.962|543|0037|Info|Transcribe is disabled
2020/04/10 16:53:55.991|543|0004|Verb|Enqueue Updated.PARAMETER.477
2020/04/10 16:53:55.991|543|0011|Verb|Dequeue Updated.PARAMETER.477
2020/04/10 16:53:55.992|543|0037|Erro|CHR: [CDR] failed to open CDR output [email protected]:3000
2020/04/10 16:53:59.268|543|0004|Verb|Enqueue Updated.PARAMETER.447
2020/04/10 16:53:59.268|543|0011|Verb|Dequeue Updated.PARAMETER.447
2020/04/10 16:53:59.293|543|0004|Verb|Enqueue Updated.PARAMETER.449
2020/04/10 16:53:59.293|543|0011|Verb|Dequeue Updated.PARAMETER.449
2020/04/10 16:53:59.450|543|0004|Verb|Enqueue Updated.PARAMETER.450
2020/04/10 16:53:59.451|543|0011|Verb|Dequeue Updated.PARAMETER.450
I configured as following:
CDR Setting: 3CX CDR service is server/passive socket
Firewall: ACCEPT tcp -- 0.0.0.0/0 x.x.x.x tcp dpt:3000

Then I make call, and check in CDRLogs there is nothing. And then check in 3cxSystemService.log showed logs as below.
Please help me explain the root cause and i must how do to solve it?

Thank you so much.

 

[chi.dinh]

Anyone?

 

[VoIPTools]

I guess it begs the question of why you are using the socket approach to CDR processing in the first place? It makes sense if you are trying to integrate with a hotel management platform that only accepts input via a socket. But for any other environment, I would NEVER use this approach.

The problem with the socket connection is that if the socket goes down for ANY reason, the data is gone and can't be recovered. Processing the physical CDR files ensures you NEVER miss any data. If your process goes down, or there is a network outage, it doesn't really matter. When connectivity comes back up, you process any files that were not previously processed.

Building a resilient socket connection is a whole lot harder than parsing a text file. So why do it? In my view the socket approach only has disadvantages. In my opinion, and you could disagree with me, processing the CDR files is the way to go.

 

[chi.dinh]

Thanks Mr. voiptoys! I think it's great advice.
So should i use choose "Single file for all calls" in CDR settings? or other better?

 

[VoIPTools]

I personally create one file per call. Since the file is created as soon as the call is disconnected, you will get closer to real-time data and it's easy to determine which calls have been processed.

I would also suggest that after you process the file, just rename the file extension and don't delete the file right away. That way if you have any questions about the original data and your parsing routine, you can go back to the source. Then, from time to time, purge the old records. Safety first, right?

UPDATE:

We do this with our Exporter tool, so we have a lot of experience parsing and managing these files. Exporter puts the data into a SQL database automatically.

I should also acknowledge that your application needs access to these files so if your 3CX is hosted in the cloud you will have to expose these files to your parsing application. We do this through our Relay application. Our relay has a file system watcher that monitors for new files, parses the data, and pushes the event data to Exporter where the data is saved in SQL. You will need to do something similar to automate the process.

 

[MichaelB_3CX]

A. Update to Update 5 Beta
B. Tell us if it happens again?

 

[chi.dinh]

Dear Mr. voiptoys

Sorry for lately posted.
Thanks for your great advice! Also, could you tell me which app and how i could use to put the data into a SQL database automatically.

 

[VoIPTools]

3CX Exporter

 

[chi.dinh]

Thank you so much, Mr.Voiptos. I am try to deploy 3cx Exporter.