URL Disabled when Internet is down.

[Roy Reynolds]

Hello all,

Does the sipxecs require the internet to be accessible to function?  I am unable to login to the web gui if there is no internet and if the outage is prolonged, the phones eventually show url disabled.  I have had this problem for years but ignored it because internet access is fairly reliable.  In this one case, I have an instance installed in an isolated site that has poor connectivity and communication is poor.  The carrier provided copper lines to the location and I have an fxo gateway connected with 4 pstn analogue lines and polycom 331 ip phones as extensions.

Is there a way to keep the services running without having the internet available?

Thanks.

[OnRelay Support]

The STUN feature has an Internet dependency, so at least make sure it is turned off.

Would also remove any public IPs and domains from settings.

If you shut down Internet and restart your server sipXproxy.log should give you an idea where it struggles during startup.

   

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sipxcom-users/7925dd41-3802-42f0-b56b-ddd58bfcc906n%40googlegroups.com.

[Roy Reynolds]

Thank you for the suggestions. I will try them and see how it goes.

I know that dns is an important config for sipxecs. Will leaving out domain names have an impact on call handling? Features such as hold, transfer and conferencing will continue to work?

I assume I can keep the ipaddress in the domain name section.

Thanks again.

[Support]

You are right, removing all domain names and public IPs may be a bit heavy handed and potentially break a working config. 

It should however be safe to just try to just turn off STUN and see if it makes a difference. 

If all your SIP endpoints have local IPs there should be no need for your local DNS server to lookup anything external.

[Roy Reynolds]

Thanks. I will try turning off stun and observing what happens.

[Roy Reynolds]

Hello, 

Just an update.

I turned off nat and simulated an Internet failure by unplugging the Ethernet cable from the wan side of my router.

After a minute I was able to access the gui interface of sipxecs. The sip device extensions remained registered and I was able to make calls. 

On reconnecting the Internet, the gui was accessible after a minute but none of the extensions registered until I restarted the sip proxy and registrar services.  They were reporting a timeout when attempting registration. 

I will dig through logs to see if I can find any clues. 

Whilst this is an improvement, it didn't solve the problem when the Internet was reestablished.

Roy.

[Support]

Hello Roy,

Instead of turning off NAT, you could try to turn off STUN.

Leave NAT Traversal enabled, and under NAT Traversal - Server Config select to Specify IP address instead of Use STUN.

Then you may attempt to leave the public IP blank there as well, in which case your local IP will be used.

To view this discussion visit https://groups.google.com/d/msgid/sipxcom-users/CALz8TxntikLZSheoc7Vv%3DFa4StPmH%2BKYqObhPmb8vbjM_PPTOw%40mail.gmail.com.

[Roy Reynolds]

Thanks for that suggestion.  I had the pbx configured as you suggested but still get the issues.  I looked in the sipstatus log and saw the following information:

:MONGO_CLIENT:WARNING:xxx.xxx.com::7f7
941c9b700:sipxpublisher:"ReplicaSetMonitorWatcher - Failed to connect to 10.x.x
.x:27017, reason: errno:101 Network is unreachable\n

I am confused as to why this would happen and the ip address it complains about is assigned to the NIC of the same host.

Could this call the calls to stop and the external fxo gateway rendered unable to process calls?

Roy.

[Support]

Hello Roy,

The mongo client connection error is probably a symptom of an earlier issue where the mongo client is not starting up / shutting down due to hanging on a public IP socket connection or similar. The corresponding log entry during loss of your iP connection (rather than regaining IP connection) should give a clue where it blocks or stops.

To 100% ensure robustness against temporary loss of a public IP connection the safe approach is likely to remove any public IP or FQD dependency from your config. 

The FQD is setup during the sipxecs-setup process, whereas a public IP is often also listed as a domain alias under Settings - Domain.

Also beware of any public IP dependencies on your disk & file system setup.

[Roy Reynolds]

Thank you.  I set the PBX ip at the public ip. So far I have no more disconnect alarms but it's only a day so I will monitor for another day. I also set a cron job to reboot the pbx daily. 

Regards,