Phones de-registering themselves

[Discovery87]

Good afternoon

I am currently tearing my hair out trying to figure out what is going on at a client's site. Any help with this would be hugely appreciated. I would even be happy paying for support right now I just can't afford to wait 48 hours to be contacted.

So far this is only affecting 4 extensions but as I don't yet know the cause I am worried it could spread.

We have 12 Yealink T42S at a client site connected to 3CX on AWS Lightsail via STUN. They have been working fine for the last 3 weeks no problems. Today at 10:40 4 extensions de-registered themselves. I don't know where to go in order to find out why? I have gone through the 3CX logs, I have exporting the Yealink logs and can't see anything.

The PCAP from the T42's shows the register request going out but I don't fully understand how to read the PCAP.

Here's the odd bit...

If I factory reset the handsets and re-provision using the link it works fine... for about 2 minutes. Then it de-registers again.

Any ideas?

Thank you

 

[eddv123]

Sounds like the firewall or a timer - but basically the port being used for registration being closed for some reason.

This is classic STUN issues at play here which is why I never suggest this setup for anymore than 1-2 handsets per site. It will work if the network setup is accurate however but this requires your endpoints to have IP addresses statically assigned/locked by DHCP or statically configured and correct port forwarding of incremented ports per endpoint (SIP and RTP).

The attached give an overview diagram I drew for the flow of each extension on 3CX, the firewall and the endpoints. Port forwarding configuration taken from a Draytek.

P.S: ensure SIP ALG is turned off on the local firewall as well - if you can however just stick an SBC in there - its free after all.

 

[JohnS_3CX]

Hello,

STUN phones require that you open permanent port forwards for each phone on the firewall at the phones site.

Each phone must be configured from the management console to have a unique SIP port and RTP range (the former being the most important as far as registration goes). These ports then get forwarded on the firewall. Ensure that SIP ALG is disabled on the firewall to avoid any unexpected interference.

Do not assume that because they worked before they will continue to do so, you are relying on the firewalls internal decision-making to get them to work and this is not going to be reliable in the long run.

You can also install an SBC if wish to avoid port forwarding, it will make provisioning and maintenance much easier for you and has built-in encryption.

 

[Discovery87]

Thank you both for your quick assistance. eddv123 the SIP ports sorted it. I will look into the SBC, I was hoping to go for an all cloud solution without the need for any configuration on site but perhaps that needs re-visiting.

 

[eddv123]

I was hoping to go for an all cloud solution without the need for any configuration on site

You still can so long as you get the configuration right, the issue being in that some people (dependent of your level of network competence) find the STUN network setup requirement a challenge.

With this being said for 12 phones you could just grab a Raspberry Pi to run the SBC, very small and if you get it in black it looks like a power supply!

https://www.3cx.com/docs/3cx-tunnel-session-border-controller/