CDR Server/Passive fails to restart after update or restart

[EarlGrei]

We use the CDR service passive socket configuration to log calls to our ERP/CRM system. We use the Passive Socket configuration. As you can see It is configured and is very basic in its setup. However the issue that we face is that whenever an update applies the socket does not start. I have to go in and uncheck 'Generate CDR', click OK, then go back in and check 'Generate CDR' again so that the socket starts back up. Anyone have any ideas?

 

[StefanW]

can you tell me more what you mean with " update applies "

 

[EarlGrei]

Like last night Update 7 applied to our server.

 

[StefanW]

I will have my team check this out and they will report back to you

 

[EarlGrei]

Thanks. We'd be happy to work with your team if they need a real-world example in case its a weird use case.

 

[EarlGrei]

I *THINK* that it fails to start the the CDR socket on start of the server. Its been a while since we have restarted the server overall but if memory serves it happens EVERYTIME the server itself even restarts.

 

[VoIPTools]

Personally, and this is just my opinion and a reasonable person could disagree, I would never use the socket connection. If your socket goes down for any reason, you lose all the calls. Your example is just one of many scenarios of how this could happen.

I have always recommended that you configure 3CX to save the CDR as one file per call, and then process the files. This approach means if your service (or socket) goes down for any reason you can simply catch up when your service is back up. You never lose any data.

 

[EarlGrei]

@VoIPTools I get that. The choice of method was not mine and ideally with the monitoring we have in place we know immediately when the socket dies anyway. I understand why DEV here made the choice they did. Also if it is known that the socket is potentially unstable then even having it as an offering is really not a good thing and it should be pulled. However if there was a functional API (that is well documented and useful) or Database access to the CDR both of our points would be invalid anyway.

 

[Cjay]

I updated my 3CX version yesterday on a RPi4 platform and the CDR (passive) socket came back up without any intervention - in my case using CallSequitur to connect. Despite other views expressed here, I (and all the other users of CallSequitur) find the CDR socket connection extremely reliable [CallSequitur will alert if there are any missing CDRs], so I'm wondering if perhaps it was your ERP/CRM system that somehow kept the TCP session open and so wouldn't reconnect after the 3CX end TCP session was restarted following the update? I say this because in my programming/testing of CallSequitur I had to implement various fail safe algorithms to recover the link in the event of a TCP session being unexpectedly interrupted.

 

[NickD_3CX]

Hi there,

My tests all concur with the above.
I just had a go at this, and after the upgrade from Update 6 to Update 7, the CDR port seems to open and TCP connection can be made to it, then for any calls made, the data is transmitted.

It goes without saying, but I'll say it anyway, during the update process, the port is closed and any TCP connections are dropped. This means that the Client Side will have to re-establish the connection again once the update is complete.