No Internet connection, not even internal calls allowed...is this normal??

[gbrook]

Hi,

Only if there is at least one SIP Trunk provider.

I fixed mine with svrlookup=no
and all addresses hard coded e.g. 192.168.0.3

Nothing else ever fixed the problem for me.

Cheers,
Garry

 

[dghundt]

tshif,
If you have all IAX voip providers for your trunks and your internet goes down, all sip extensions on LAN still work. I do not have any remote extensions (just internal LAN), so cannot say what happens if one uses sip or iax remote extensions.

gbrook,
I have tried various srvlookup workarounds in the past and never had any luck. Can you post what your exact setting changes are, especially what are you hard coding as 192.168.0.3 and where you are doing it? Also, are you still using fqdns for your sip trunks or pure numerical ip addresses? Asterisk version as well.
If we can reproduce a simple workaround this will be a boon for everyone. I really would like to have voicepulse again. Thanks

 

[gbrook]

Hi,

My sip_general_custom is as follows
; Anything that is not to be overwritten during
; updates or upgrades is to be put in this file
; otherwise FreePBX replaces sip.conf with a standard file.

srvlookup=no

;-------------------------------------------------------------------------------------
; Home - This prevents any issues with one way voice.
;-------------------------------------------------------------------------------------
nat=yes
externip=xxx.xxx.xxx.xxx ; Home Static IP Address
externrefresh=10
localnet=192.168.62.0/255.255.255.0 ; The first 3 octets the local IP addresses
;qualify=yes

If for example my Asterisk server is 192.168.62.1 then all phones are pointed to this address not say home_asterisk.localdomain

With regards to IAX and SIP trunks they are all pointed to the numeric address not the fqdn.

Even with all this done except srvlookup=no entered it never worked during Internet loss it was only once I then inserted srvlookup=no that it worked.

Cheers Garry

 

[cjkeeme]

I haven't tried this, but the guys over at freepbx.org seems to think they have a solution to this issue.

freepbx.org/support/documentation/howtos/how-to-install-bind-so-that-sip-extensions-continue-to-work-when-intern#comment_form

 

[dghundt]

pick your poison with each work around.

Although this will keep you from losing SIP connectivity during an Internet outage, it will only work as long as the system is not rebooted.

gbrooks method is probably better, only issue is if your voip provider changes their ip address.

At least with the ping test work around, you should not have issues if you reboot your machine. If I happen to be out of town when my office loses internet, I really don't want to spend part of my day fixing things.

 

[bluetrepidation]

Can someone clarify? Here is my setup: PIAF 1.4 w/ Asterisk 1.4.21.2 and Aastra 57i phones. I have absolutely NO SIP or IAX trunks setup.

Now if I disconnect the WAN this breaks DNS and I have the following issues:

1) The main PIAF page will not load and times out.
2) Logging in via SSH is sluggish.
3) Once SSH longs in the Daemon Status takes a long time to bring up the "Running Asterisk Version."
4) Aastra phones eventually say "No Service."

Now I set up a local DNS cache with Webmin which fixes:

1) Internal SIP calls work and Aastra phones do NOT go into no service.
2) SSH longs in without being slow.

The following issues STILL exist.

1) The main PIAF page will not load and times out.
3) Once SSH longs in the Daemon Status takes a long time to bring up the "Running Asterisk Version."

These are my observations using the following lab setup:

I will try a reboot of the server without a WAN connection and see what happens next.

Thanks,
A.J.

 

[bluetrepidation]

Internal calls work after reboot.

A.J.

 

[jroper]

1) The main PIAF page will not load and times out.
3) Once SSH longs in the Daemon Status takes a long time to bring up the "Running Asterisk Version."

The PiaF page is bringing in an RSS feed. Switch this off, and your front page will load.

The Status pings google to make sure the PBX has connectivity, it takes a while for that command to time out before displaying.

Joe

 

[dghundt]

The PiaF page is bringing in an RSS feed. Switch this off, and your front page will load.
Joe

Where pls?

 

[darmock]

Man I thought my lab was cluttered with computers!......


Tom

 

[jroper]

Admin section of the front page.

Joe

 

[manugmedia]

bluetrepidation,
Jeez! what a lab! my 3 server's and one hosted, 2 IP phones and 2 ATA's look kidish now. Waoh! Good topology Man!.

 

[bluetrepidation]

Most of those computer are broken. If anyone wants some old lamp iMacs of parts for G5 iMacs let me know. I'd rather not throw this stuff away. Otherwise it'll eventually make it to ebay. The place is A MESS!

Thanks for the reply. So everything is functioning normally. I'll have to turn off the RSS feed for now. I guess if I where to add a SIP trunk to this system if where the fun really begins if DNS is knocked out?

A.J.

 

[tshif]

If it is fixed, it should be back ported to 1.4.
It wasn't working in 1.2 either.

Does anyone know if the fix HAS been backported to 1.4? If so, what version/rev/ etc?

We have been most fortunate in that all our deployments already have local DNS servers - so I have literally never seen this happen. BUT it scares the crap outta me reading the horror stories here, and Id like to deploy a patch if one exists.

 

[briankelly63]

There are lots of threads in lots of places about this problem. all involve workarounds that make sure that DNS never goes completely silent during these SIP related events, at least locally. In a sense its not an Asterisk issue since apparently until recently their haven't been any non-blocking DNS lookup code modules available in Linux.

Remember Asterisk simply talks to the underlying OS and requests the DNS lookup. Having said that Asterisk could be designed or modified in a way that circumvents this issue. It is reasonable from a design standpoint to assume that this issue would arise on a regular basis and should have been factored into the design of Asterisk. I think there is a disconnect (no pun intended) between the design objectives and programming habits applied to general computer applications vs. mission critical, bullet proof, redundant and fault tolerant telephone systems... A big disconnect.

Asterisk has tended to be on the general application side of the equation in terms of its lack of hardness. This sort of massive pothole in Asterisk should have been patched years ago. A separate process could monitor the health of DNS lookups and prevent the main Asterisk thread from making calls that are destined to fail. Some of the solutions you'll see on the boards attempt to do that by dynamically disabling SIP trunks if there is no DNS.

Anyway there certainly are fairly easy ways to fix this through DNS caching and other methods, just pick one.

Brian

 

[dghundt]

This sort of massive pothole in Asterisk should have been patched years ago.

I agree. It is frustrating to no end.

Anyway there certainly are fairly easy ways to fix this through DNS caching and other methods, just pick one.

I have searched for an "easy" way to fix this and never found one without some negatives. Particularly, I still want to use fqdn instead of a numerical ip address for my sip trunks.

If you have an "easy" way to fix this using fqdn's I and many others would be grateful for your walk through instructions. I would like to start using sip trunks again.

 

[briankelly63]

See these links and text...

I've also seen BIND set up via webmin as a caching server as long as the time to live is set for a high value...

https://issues.asterisk.org/view.php?id=3723

http://www.elastixconnection.com/index.php?Itemid=88&id=65&option=com_content&task=view

Solution listed on Freepbx site:

On October 30th, 2009 csabka (tadpole) said:
1. Just reject the 53 udp&tcp port in case of internet outage with iptables rule.
e.g:
iptables -I OUTPUT -p udp -m udp --dport 53 -j REJECT
iptables -I OUTPUT -p tcp -m tcp --dport 53 -j REJECT
iptables -I OUTPUT lo -p udp -m udp --dport 53 -j ACCEPT
iptables -I OUTPUT lo -p tcp -m tcp --dport 53 -j ACCEPT 2. Use dnsmasq (DNS proxy) with some tricks:
/etc/resolv.conf only contain:
search aaaaaaaaaaaaaa.aa
nameserver 127.0.0.1 /etc/resolv.dnsmasq:
nameserver 208.67.222.222 (or any other real recursive DNS server)
nameserver 208.67.220.220 /etc/dnsmasq.conf fit your needs and:
resolv-file=/etc/resolv.dnsmasq
address=/aaaaaaaaaaaaaa.aa/127.0.0.1 If you use DHCP client or PPP connection then the original resolv.conf could be automatically changed. So you must overwrite it all time (by script). Maybe use chattr.
Results: asterisk will not slow down
1. answer will be unknown host inmediately.
2. e.g: try to ping example.com. In case of internet outage, example.com will fail, so after 2-5sec by the "search" option example.com.aaaaaaaaaaaaaa.aa will be queried. After that the answer will be 127.0.0.1.
If the DNS server could be reachable, then the correct ip will be resolved.

 

[borsaid]

Sorry if this is way off base, but I've yet to completely wrap my head around the problem (I'm getting there though). . . but if we point the DNS queries to an internal DNS server that caches those DNS queries, will that solve this whole problem?

We have a few internal DNS servers that use forwarders to our external DNS servers. I'm sure I can get one of them to provide some kind of caching function.

 

[blanchae]

The PiaF page is bringing in an RSS feed. Switch this off, and your front page will load.

You can disable it in the Menu Config interface - this is the 3rd button next to FreePBX and Webmin on the initial PiaF menu.

The Status pings google to make sure the PBX has connectivity, it takes a while for that command to time out before displaying.

Joe

What would be nice is for status to ping the PiaF configured default gateway then have it perform a nslookup of a known site such as pbxinaflash.com. Having it display the results would be great!

That would verify network connectivity and that DNS is working. Just having that information would help solve a lot of problems.

 

[dad311]

Eight pages later and I still think the best solution is to avoid SIP trunks and use IAX if possible.