Solved V18 Upgrade Ring Group Issues

[easttek]

I currently have 3cx install "locally hosted" on a Nuc Machine, I finally got around to upgrading to V18 earlier this week. The only issue I had with the upgrade was Debian did not remember my local static IP and reset the nic to DHCP, simple fix. The firewall check is good. I have a dozen or so Fanvil X6s and Fanvil X4s (firmware all up to date) in a ring group set to ring all, since the upgrade all of the X4s stopped ringing on incoming calls. The activity log is showing all X4 phones getting a '408 request timeout/INVITE from local' error when someone picks up instead of the standard 'request terminated/INVITE from "IPADDRESS"'. I have tried rebooting the phones and server and changing the sip trunk transport protocol. Any ideas?

 

[easttek]

Meant to also mention Flowroute is my provider

 

[Saqqara]

What happens if you create a new ring group and add the x4 phones one by one

 

[easttek]

What happens if you create a new ring group and add the x4 phones one by one

Sorry, I should have also stated I did delete and rebuild the ring group also. I haven't tried adding the phones one by one though do you mean add one and try to call, then add 2 then try to call, etc?

 

[Saqqara]

Correct add one phone at a time, then test - hopefully you will find the extension causing the issue

Do any of the extension, have ring my mobile at the same time

 

[easttek]

Correct add one phone at a time, then test - hopefully you will find the extension causing the issue

Do any of the extension, have ring my mobile at the same time

Will attempt this after hours. No currently no extensions are utilizing that feature.

 

[easttek]

Will attempt this after hours. No currently no extensions are utilizing that feature.

Correct add one phone at a time, then test - hopefully you will find the extension causing the issue

Do any of the extension, have ring my mobile at the same time

Added a dummy number with a DID rule directly to an extension that wasn't working, the phone does not ring. Went down the list and tried each not working extension, the phone does not ring. Getting the same error in activity log 408 request timeout. All the X4s. If I DID an X6 I get through no problem. So strange.

 

[Saqqara]

Silly question, the phones ring if called directly

 

[easttek]

Silly question, the phones ring if called directly

No

 

[cobaltit]

Factory reset a phone and re-provision and see if that works

 

[leejor]

Interesting...came across a similar issue, also using Flowroute, from 2017. Go to the end of the thread.

https://www.3cx.com/community/threads/incoming-call-not-ringing.52535/

 

[ChrisC_3CX]

I'd recommend first trying what cobalt it mentioned first:

Factory reset a phone and re-provision and see if that works

Also, if the issue persists, could you provide the exact firmware version of the Fanvil X4's you're using?

 

[easttek]

Ok so we can mark this as solved. While going through every setting i possibly could i noticed that under the network tab there were two available IP addresses on a machine with a single nic card. My static IP set in debian and what I can only assume was the original dhcp address. I set debian back to dhcp and reset the network services, it pulled that second address. Mind you this is with a IP reservation for my static IP bound to the machines mac in the router config. Then, set static again, reset network services and rebooted the machine. Then I had a single IP available in the network interfaces.

So, not sure what device is responsible here. Its possible that the router ignored the IP reservation for an older dhcp lease? However, the 3cx automatic update did set my nic from a static IP in debian 9 to dhcp in debian 10. Either way, the X4s are ringing again. Thanks for the help guys, hopefully this thread can be informative for someone else!

 

[ChrisC_3CX]

Previously you had mentioned that you had static IP set on the NIC, if however what you had instead was a DHCP reservation based on the MAC address, then what you experienced is actually expected due to a change in behavior on the OS level from Debian 9 to Debian 10. There's a similar thread about this here: https://www.3cx.com/community/threads/upgrade-to-v18-mac-address-changed.87982/

In any case, glad to see you got this sorted! I'm sure the info here will help others too.

Please feel free to start a new thread should anything else come up!