Phones randomly unregistering or showing they are registered but actually not connected

[VoyantPhone]

I have a client with 23 phones, all of them Grandstream 2170s. Connected to the 3CX cloud based system. Using the most recently updated version 16. SIP ALG is turned off in both the router and modem. Tried letting the phones connect with STUN without using the SBC, tried using the SBC, and now have each phone back on STUN, but each phone has its own port to itself (5066 through 5089, so no conflict with 5060, 5065 or 5090).

In all of the above cases, each day, a random phone or two will unregister. it's not always the same phones. Sometimes the phone itself will say it's not registered, sometimes the phone will show that it is registered, but it actually isn't, as it doesn't appear in the "Phones" page on the management console. Rebooting the phone will register it again, no problem. But since my client has to reboot a phone or two each day, he's starting to believe the system is unreliable.

Something must be wonky in the network, but I cant figure out what. Any good idea's out there about what the problem is? I'm starting to pull my hair out.

 

[AWS2P]

If phones are unregistred all using STUN, then probably your problem is on network and the master piece is your router/firewall,
So for now your phones are STUN or behind SBC?
What did you use for SBC ? a PI or stronger computer on Windows ?

Using an SBC you need nothing else than 5090 and 443 or 5001. no ports change needs to be done on phone location router unless you use very strict rules for outgoing traffic.

 

[AWS2P]

what have you done(give details please) to change phones from STUN to SBC

 

[VoyantPhone]

Created an SBC on a windows machine in the office, and in the phone provisioning for each phone, directed them to the IP of that windows machine. Still had the random unregistering that I got when the phones were originally set on STUN. Now have them back on STUN, but the "Local SIP Port of Phone" is now a different one for each phone (between 5066 and 5089). I haven't seen any difference in the random unregistering of phones in any of the 3 setups.

 

[VoyantPhone]

I am considering going back to the SBC setup, but this time attaching one of those mini PC's that aren't much bigger than a USB drive to the network and putting the SBC on that. That way the mini PC's only task will be to run the SBC with no other apps running on it. Not sure that will work, still looking to see if there's something else I need to set (or disable) on the router or elsewhere in the system to stop this from happening. Any other suggestions?

 

[AWS2P]

The only thing on router is to disable SIP ALG , as you saitd it's done so nothing else on this side.

When you changed phones from STUN to SBC did you factory reset them after you changed the settings on each extension on 3CX ?

 

[AWS2P]

did you see IP adress from each phone connected as one from SBC like this

 

[cobaltit]

When switching from STUN to SBC the recommendation is to factory reset the phone and then use PnP to provision it via the SBC. Also, please confirm you are on the latest 3CX available firmware and stock template.

 

[VoyantPhone]

When on the SBC, the IP addresses were correct - they looked like what you showed above. We are using the most recent firmware and templates. The system is set to check and update automatically every night.

The only thing we did not do was to factory reset the phones before changing them from STUN to the SBC (or when we changed them back again to STUN, but each with their own ports). I find it hard to believe that would be the issue. Has anybody else had similar problems that were resolved once the phone was factory reset and then reprovisioned?

 

[AWS2P]

Phones can keep settings from STUN mode even they are set for SBC if they are not factory reset before being provisionned

 

[AlexanderReichert]

that sounds like this Grandstream problem which I am hunting down since months. https://www.3cx.com/community/threa...-going-offline-daily.72258/page-2#post-329054

even opened a ticket with Grandstream but it is super hard to reproduce. Grandstream wants a syslog dump from the phone with the SIP log included (if you change the syslog server in the phone to 1.1.1.1 it stores the syslog on the phone and you can download it before you reboot the phone)

 

[HRMNY]

You might need 3CX Support to remove them from Grandstream's RPS. I've had that happen before when switching to SBC. You will need a picture of each phone's mac address for them to do it.

 

[AWS2P]

uhmm ....not sure the need to pay a support ticket if you are not partner just to remove mac adress in rps server, cost too much IMO.

 

[JohnS_3CX]

Please reset your phones, and assign them to your respective extensions via the Phones tab as soon as they appear there as "New" via your SBC. Some models may misbehave otherwise and you will endup chasing phantom issues if you don't reset first.

The SBC will now become the thing you need to monitor: if it also disconnects then you should inspect the network in this fashion: Local network -> Firewall -> Modem

 

[VoyantPhone]

Went to the other thread suggested by @AlexanderReichert, and saw one response that said:

"Had a response from Grandstream Support.
Create a new Handset Template with these changes to these P Codes:
P52=2
P2397=1
Then push these templates to the affected phones."

The post was from May. Has anybody tried this solution for more than a few days and found that it worked?

 

[JohnS_3CX]

@VoyantPhone

Careful - That might affect the audio if not set correctly for your specific provisioning method

 

[VoyantPhone]

How would it affect the audio? I have only changed those 2 parameters on a few selected phones, all GXP2170s. So far, so good, but it's only been a day.

Has anybody tried this with success over a longer period of time? This is a much easier fix than moving all the phones back to an earlier firmware version.

 

[JohnS_3CX]

If the STUN setting is disabled the phone might end up sending its local IP in the SDP, hence the incoming audio may stop.

 

[VoyantPhone]

Not having any audio problems so far. Again, has anybody else made these template changes above and had long term success with phones no longer unregistering?

 

[VoyantPhone]

Unfotrunately, it appears that these template changes slow the number of times the phones randomly unregister, but ultimately do not solve the problem. The last few days I've had some phones with the customized template unregister. Right now I am wasting time babysitting the most recent systems I installed, constantly checking for unregistered phones (that still think they are registered).

There is a firmware upgrade for the 2170's that 3CX has not approved yet. Not sure why it hasn't been approved. Has anybody upgraded to the newer firmware for any length of time? Did it solve the unregistering problem? Did it create other problems? Anybody out there able to share their experiences?