V20 Update 8 Release Candidate

[fxbastler]

Yes, we do sometimes have bad luck, but we expect that beforehand and we can handle it - because we have to, for ourselves.

As life goes: I shouldn't have written that so clearly yesterday.

Our 3CX RC crashed cleanly into the wall this morning. The first time in months.
Only a few incoming calls were going through, no outgoing calls, the web interface was inaccessible and the operating system also crashed. There seems to be an issue with logging or log archiving - we are still analyzing the remaining log files. However, a cold reboot (briefly turning off the IP power strip behind the UPS) temporarily solved the problem.
We expected this and have built in appropriate reserves.

 

[nikolascx]

@fxbastler
When did you perform the update?
At the moment of updating, the system is fully reloaded, so we can safely say that whatever caused the failure occurred after that point in time.

I seriously doubt this is related to the RC itself, as no core service changes were introduced at that stage. If there were no configuration changes made after the update, the most common causes we typically see are resource exhaustion (CPU, RAM, disk, or I/O) or a call routing loop.

If you’d like, we can analyze this together. Please upload the relevant log files and send me the link via PM.

System event logs will be especially useful, as well as any indication of which service failed first.

Happy to take a closer look with you or your team. Take care

 

[fxbastler]

When did you perform the update?

to v20: 02/2024 I think
Since then updates are usually applied just a few minutes or hours after the version is released. I have the 3CX blog as feed on my smartphone (Flym) and sometimes we monitor the 3CX repo

If you’d like, we can analyze this together. Please upload the relevant log files and send me the link via PM.

Thank you for your offer, dear Nikolas. We'll handle it ourselves as always. If it really turns out to be a fundamental and reproducible issue with 3CX we'll reach out via PM as usual. Thanks again.

the most common causes we typically see are resource exhaustion (CPU, RAM, disk, or I/O) or a call routing loop.

atm and according to the log files it's none of those. The system is also monitored via Zabbix. Nothing stands out in that direction.

The disk is fine and the rest of the hardware as tested is also good. The problem seems to have occurred during the log rotation, so it's an operating system issue. We've never had that before. I can't reproduce it either.

I'm not too concerned about it at the moment. We'll put the case aside for now. If it happens again, I'll look into it specifically. We have more than enough resources in terms of logs, hardware, software, backups and phone system replacement / failover - so it's all good.

 

[nathan0707]

We were using the 3cx Transcription any ETA when we can purchase the AI credits for the NFR license we would like to it again. Or is there any guidance on how to get the local 3cx Transcription running with Stero mode for AWS hosted instances?

View attachment 50543

I prefer to purchase credits rather than use the local GPU as that will require additional cloud resources more likely to have an issue that can effect the call performance, would rather keep them separate anyway

 

[KyriacosS_3CX]

We were using the 3cx Transcription any ETA when we can purchase the AI credits for the NFR license we would like to it again. Or is there any guidance on how to get the local 3cx Transcription running with Stero mode for AWS hosted instances?

I would say speak with your sales contact for the NFR - NFRs tend to be a specific type, that may not be able to access the 3CX cloud AI.

For the local transcription - just follow the setup guide. You can get a GPU host from a number of cloud providers, or host your own, and then connect with it - it does not matter if your PBX is AWS and the GPU host is for example Google - as long as they can talk to each other over the internet the transcription works.