I have an asterisk 1.4.2 embedded system and after loosing internet connectivity (ISP problems) i realised that * would not answer an outside call (from PSTN / FXO) or any call from any extension. I found that the CLI was displaying an expected error about my SIP VOIP account registration and was trying to register, got timeout and pause for 20 sec. and try again to register with the VoIP provider.
I found that * would only answer when doing that 20 sec. pause and as soon as it was trying to register it stopped replying …
The CPU usage when registering was low … but no answer … The CLI seemed normal …
Then i removed my register line in sip.conf and restarted and everything got back to normal. which clearly indicate that the problem is with the registration to the voip provider …
This is quite annoying as i expected to be able to do normal calls to the other ext. and using the PSTN line when the Internet is down …
Anyone has an idea on how this can be fixed ?
Should this be reported as a bug ? (Is it already known ?)
Tnx for any help …
A customer of mine experienced the same one time, the only time they had the connection to Internet broken; should be a thread in the forums about but I can’t find it…
I tried and no changes …
But it gave me the occasion to do some more testing …
Actually if you disconnect the system from the wan …
it get stuck like this on all DNS lookups and it seems to block eveything in all * processes … It actually takes 4-5 mins before it finally gets to the “Asterisk Ready” prompt !!! (?)
As before it would answer an ext. only in the 20 sec. pause in between registration retries (which take > 1 min to timeout) …
Then i replace my sip registration domain name by the actual IP address and … it now no longer “blocks” on the registration attempts … which again indicate a DNS problem (DNS requests block everything when no WAN connections)
So this might not be an * problem at all but maybe a dnsmasq problem / bug (?)
Has anyone been able to configure an hybrid * (FXO/ VoIP) and get it to work normally without an internet connection ?
The DNS blocking is a known issue. If I remember correctly, I believe I saw a commit to the trunk code to improve this or fix it all together.
[quote=“noelbiou”]
Has anyone been able to configure an hybrid * (FXO/ VoIP) and get it to work normally without an internet connection ?[/quote]
If you mean failover from VoIP to FXO, best to put a qualify on the Voip peer so it will failover quicker to the next priority in the dialplan and dial out the fxo.
I reported this problem months ago, sadly nothing appears to have been done about it. The developers seem to be in denial. Plain and simple fact is, that if * cannot resolve a DNS entry, it is to all and intensive perposes dead! Using an IP address gets around this issue. But that’s not ideal.
I even posted a solution that checks if the internet is up and modifies * to work around the issue, but this was ridiculed. THIS IS A SERIOUS FLAW, but heck, I’m only a user with 25m/year calls going thru *
Well … i really think that this is a serious flaw as it implies that an “hybrid” PBX could not work when the INet is down …
which makes the system completely useless … (and users complaining with good reasons).
I imagine that the DNS request could return immediately with the proper error msg in these conditions …
The idea of changing the config in realtime is admitedly at best a as it could get complicated with a system registering to multiple VoIP provider and other asterisk systems … A fix at the source of the problem is what is needed …
… but alas, i don’t know enough to be of much help for this …
Perhaps you could do DNS differently for the Asterisk server…
Setup the Asterisk server to run named locally as a caching-only DNS server.
Then tell the Asterisk machine to check itself for DNS. If nothing else is using the Asterisk server as it’s primary DNS, it shouldn’t have more DNS network traffic than it would normally have had, but if the master(s) become unavailable, it would retain a cache of the DNS infromation it needs.
That might hold things until the WAN connection is restored, and after that, named should restore things on it’s own.