- Joined
- Aug 18, 2022
- Messages
- 2
- Reaction score
- 0
Set-up info:
Both ring groups are set-up as hunt-groups and have a "last-resort" forward to a different physical building(external number), if nobody picks up.
The problem: at some point the ring group virtual extension marks itself as "unavailable"(?) then all the calls go the "last resort" route to the different building. Rebooting the 3cx host fixes this for a few hours, then the problem reappears. I have verified both Ring Groups exhibit this behavior. Interestingly, doing the firewall check also reboots some services, but does not fix the problem like a full host reboot would.
I have attached an anonymized log file excerpt.
- 3CX Version 18.0 (Build 965)
- Server OS Debian GNU/Linux 10 (buster) - Came with the 3cx iso
- Is the 3CX Server Hosted and where? On-Premises, VM
- IP Phone Make/Model/Firmware version, Yealink T46S
- Provisioning Method: Local
- Trunk Provider or VoIP Gateway Make/Model, Local telecom provider SIP VOIP trunk (tet.lv)
- Has the Firewall Checker passed: Everything passes, except for SIP ALG, that is confirmed to be turned off on our Mikrotik router, it has been that way since day 1 and worked fine for us so far.
- Are custom Phone Templates being used: No
Both ring groups are set-up as hunt-groups and have a "last-resort" forward to a different physical building(external number), if nobody picks up.
The problem: at some point the ring group virtual extension marks itself as "unavailable"(?) then all the calls go the "last resort" route to the different building. Rebooting the 3cx host fixes this for a few hours, then the problem reappears. I have verified both Ring Groups exhibit this behavior. Interestingly, doing the firewall check also reboots some services, but does not fix the problem like a full host reboot would.
I have attached an anonymized log file excerpt.