Some ATA’s won’t reregister

[complex1]

Hi,

I have an annoying problem.
On my 3CX v11 SP4 I have several external extensions (outside the LAN). They are a mix of SPA3102, 2102, 1001, Snom M3 and N300A IP. Everything is working fine but after a glitch of the internet or router the SPA’s lose their registration and never reregister until the devices are rebooted manually. Then everything is working again.
The Snom and N300A always register immediate as soon the internet is back again.
Can someone tell me what/why cause this and how to solve it?

Thank you.

 

[leejor]

after a glitch of the internet or router the SPA’s lose their registration and never reregister until the devices are rebooted manually.

A "glitch" could be used to describe any number of things. Since the phones worked up to that point, and nothing on them has changed.....

If the sets have a syslog server, you may have to enlist it's help in determining what is different, in the registration attempt, after a re-boot. Does the 3CX log show that they are even getting through but are being rejected for some reason? If there is no sign of an attempted registration then you'll have to go over the settings within the set. It would then sound as if the destination, of the server (as programmed in the set) is not reachable. It shouldn't be wrong, as it had been working. Do you send to the server at an IP, or URL? Do you use a Dynamic DNS service, perhaps, that has been updated , but not acknowledged by the sets? Given it is only one make of sets, it would be assumed to be a common setting. Are you set to use STUN? Perhaps the registration is getting to 3CX but nothing is getting back to the devices. While STUN should be longer be necessary, on the newer versions of 3CX, there could be a setting in there that is causing this.

You might try manually provisioning one line on, say, the 2102,with just the basics (name, password, server, etc.. and see how that works. If it does, then compare with a device still having the issue. You might want to consider a factory reset to clear settings besides just those in the Line tab.

 

[complex1]

Hi leejor,

Thank you very much for your reply.

The ATA’s losing their registration if the internet connection fails at the 3CX site or at the ATA site. This is normal.
(connection fails like: temp. disfunction of ISP, reboot router, power down, maintenance by ISP)

The ATA’s are located behind different type of routers and spread-out over different locations, except one SPA2102 and one Snom M3. They located on the same site. So, why the Snom successfully re-register and the SPA won’t re-register, I don’t know.
BTW: only the SPA’s do not re-register, other ATA’s registering normally after an internet fail.

It does no matter on which site (3CX server or remote extension) the internet fails, the problem starts.

In 3CX log is no activity of the registration process shown, only after a manual reboot of the ATA.
It looks like something is holding the registration process between ATA and 3CX.

All devices are using STUN and the Proxy field is setup with a Dynamic DNS name. As STUN server I use stun.sipgate.net, not the 3CX server.

I have also checked the IP address where the 3CX Sever is located and that address is for more than 4 months the same –it didn’t change. Also have checked this at DynDNS.org site, no changes of IP.

All ATA’s are setup manually, not by provisioning.

As long as the internet connection is stable, there are no problems of whatsoever and for a long time....

Soon I'm going to use a HT701 as a remote extension (oversea). I am curious how this device will behave after an internet connection fail.

Thank you.

 

[complex1]

I think I’ve found the solution, not sure, in the SPA's I have filled-in the “Outbound Proxy” field, changed the SIP Timer Values "SIP T1" into 1 (sec) and it looks good now.

 

[leejor]

Unless you use a provider that specifies the use of a proxy, or, you have a proxy server installed at a remote location along with the set(s), I don't think that filling in that field should make a difference, although it shouldn't hurt either.
The timer settings can make a big difference if the defaults are way off what is to be expected, or, as you have found, when there are "unusual" network "circumstances".