TUTORIAL Use PBX with Internet Outage: DNS Cache

[ukiechris]

I have a local server running PBX in a Flash. Using Aastra 55i endpoints exclusively. The system is working fine during this testing stage. Before official deployment I wanted to explore the "offline" option for the PBX by adding four PSTN trunks using Cisco adapters (leaning towards four SPA3102, or SPA400).

Currently, without any PSTN trunks connected into the PBX when the internet goes down the endpoints can dial voicemail (*97) but not other extensions, since dialing 101 on the phone dials 192.168.0.101.

My goal is to deploy 4 PSTN trunks and put them below the main VoIP trunk for outbound calling. My question is would this be possible and has anyone done this?

Secondly how to make Aastra 55i phones to dial internal extensions when the connection to the internet is lost.

Once again, this is on a local PBX server.

 

[atsak]

Read this thread:

http://pbxinaflash.com/community/th...ernal-calls-allowed-is-this-normal.245/?t=245

And install BIND on the server. Should work fine in an internet outage.

 

[dghundt]

wish it was always that simple for all users.
the fix should be done within asterisk code.

 

[darmock]

This problem has been around since I became involved with asterisk... many years ago. Early on I took the time to try to contact the asterisk developers and suggest they perhaps wanted to fix this minor feature......

I was told that it was a feature and not a bug and to not so politely to piss off.

There have been a number of kludges over the years but no real attempt to fix the underlying feature...er bug. I had it happen to me yesterday on my office system which has a couple of dns servers which both failed....

I agree there should be a "switch" that users could "throw" that would cause the system to work when sip trunks fail and it should be internal to asterisk not a kludge... This only seems to affect the SIP trunks as pots and iax do not seem to cause this problem.

I feel your pain..... 8^)

 

[wardmundy]

Experimental (and hopefully final) Solution

Here's what works for us. You've got to have a Bind DNS Caching Server running on your PIAF box to keep it going with an Internet outage. If you use FQDNs on phones, then the primary DNS address must be the internal or external IP address of your server depending upon where the phones are located.

Here's a simple script to install and get bind running properly (we hope). Log into your server as root. Then...

yum -y install bind*

cd /var/named
service named stop
wget http://pbxinaflash.net/source/bind/bind.tgz
tar zxvf bind.tgz
rm bind.tgz

echo nameserver 127.0.0.1 > /etc/resolv.conf

sed -i 's|$nameserver|127.0.0.1|' /sbin/dhclient-script

service named start
service network restart

dig pbxinaflash.com
dig pbxinaflash.com

# look at the output for the second dig command issued above
# 2d dig command should show a very short DNS lookup time, e.g.
#;; Query time: 1 msec
#;; SERVER: 127.0.0.1#53(127.0.0.1)
# IF ALL IS WELL...

#be sure to set named for auto start on bootup

chkconfig  named  on --level 2345
chkconfig --list named

# named should be configured to start with RunLevels 2,3,4,5

IMPORTANT: When you're finished with the above, run a dig command (e.g. dig inbound1.vitelity.net and dig outbound1.vitelity.net) for each of the FQDNs of your SIP trunk providers! Better yet, do amportal restart to be sure all of your trunk providers get cached. Don't forget the ones that don't require registration to make outbound calls (such as Vitelity) as these won't be in the list! This dig procedure caches the IP addresses of these FQDNs on your server for a rainy day. You can find the info with FreePBX: Tools, Asterisk Info, SIP Info, SIP Registry. This doesn't mean you can still make calls through your service providers even when the Internet dies. What is does mean is that Asterisk can decipher the IP addresses of your SIP providers and won't disable use of your phones to make local phone-to-phone calls during the outage.

 

[dswartz]

Minor nit, Ward: said DNS server doesn't need to be running on the PIAF box, just somewhere on the LAN.

 

[drmurdoch]

> yum -y install bind*

ftp://ftp.mondorescue.org/fedora/5/repodata/repomd.xml: [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory.
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: mondorescue. Please verify its path and try again

I installed BIND via clicking
BIND DNS Server in Webmin.

 

[drmurdoch]

#;; Query time: 1 msec

> dig did.voip.les.net

; <<>> DiG 9.3.4-P1 <<>> did.voip.les.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58935
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0

;; QUESTION SECTION:
;did.voip.les.net.		IN	A

;; ANSWER SECTION:
did.voip.les.net.	2779	IN	A	64.34.181.47

;; AUTHORITY SECTION:
les.net.		2779	IN	NS	ns9.ca.les.net.
les.net.		2779	IN	NS	ns1.ca.les.net.
les.net.		2779	IN	NS	ns1.us.les.net.

;; Query time: 144 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Apr  6 21:28:47 2011
;; MSG SIZE  rcvd: 110

> dig did.voip.les.net

; <<>> DiG 9.3.4-P1 <<>> did.voip.les.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45531
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0

;; QUESTION SECTION:
;did.voip.les.net.		IN	A

;; ANSWER SECTION:
did.voip.les.net.	2770	IN	A	64.34.181.47

;; AUTHORITY SECTION:
les.net.		2770	IN	NS	ns1.us.les.net.
les.net.		2770	IN	NS	ns9.ca.les.net.
les.net.		2770	IN	NS	ns1.ca.les.net.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Apr  6 21:28:56 2011
;; MSG SIZE  rcvd: 110

Looks like it is working

 

[drmurdoch]

If you use FQDNs on phones, then the primary DNS address must be the internal or external IP address of your server depending upon where the phones are located.

"If you use FQDNs on phones.."
I believe I do.

I use SIP via les.net for it's trunk the
PEER Details:
host=did.voip.les.net

how would I verify what my primary DNS is ?

Does this help ?

> cat /etc/resolv.conf
nameserver 127.0.0.1

The IP of my PIAF box is 192.168.1.XXX.

 

[darmock]

Just a minor point please go into /etc/yum.repos.d and delete the mondo repo. It no longer works and we are now hosting the latest stable version. That will get rid of the error you see when yum runs.

As for BIND sorry I run DNS off of win server 2008. I have been meaning to work with BIND but who has time.


Tom

 

[drmurdoch]

Just a minor point please go into /etc/yum.repos.d and delete the mondo repo.

Tom

I deleted Mondo.
This is what is left

> ls /etc/yum.repos.d
CentOS-Base.repo
CentOS-Media.repo

 

[darmock]

Which is all you should need.


Tom

 

[wardmundy]

Just to amplify, if you have phones that are external to your network, you can use any DNS you like on those phones. If the Internet dies to your server, these phones won't be able to get there anyway. We use Google's DNS servers:

8.8.8.8
8.8.4.4

 

[Irnadd]

I have phones that are external to my network but when the internet comes back-up at the data center the phones take forever to register again or some can make outbound calls but not receive calls. I do not have the DNS configuration set up yet from what you mentioned above will this DNS configuration resolve these type of issues as well.

 

[wardmundy]

External sources still are dependent upon DNS. If you want to reduce the time, use the IP address of your server on the external phones instead of an FQDN.

 

[Irnadd]

Thank you, i will try that on some phones and see how it works out. I use noip.us now for the FQDN on al my phones instead of the IP it self. I thought it would be the same response time so thats why i used it in the first place. I guess what really puts me in a loop is that some phones that are in europe on the other side of the world register right away and others that are right next to the center do not register for yet a while.

 

[wardmundy]

The response time for an IP address and an FQDN typically would not be noticeable except when the FQDN is not available in all of the DNS mirrors. If your provider's servers are down long enough for that to happen, it's probably time to consider a different provider.