Asterisk and the loss of Internet

Did you even bother to read the OP ?

We have two nic cards in our TB. One for internal and one for external. I just unplugged the internet connection and no problem. PRI and phones all worked. We are not using 2.6 inhouse yet.

this is a known bug in Asterisk. There is quite a discussion of various ways to fix it on the pbxiaf site.
See posts 22 and 23 in this thread: http://www.pbxinaflash.com/forum/showthread.php?t=245&highlight=i.... Ward's translation of the Australian solution worked for me.

There is still something wrong here though. I have an internal DNS server that long term caching or not will always resolve internal domains. My phones connect via an IP address (ironically to keep them running if the file server dies). So what is happening with a caching DNS server is that it must be caching the *external* domains that aren't going to work anyway when the net is down but it makes asterisk happy to have resolved it. The phones should still connect to the PBX on the same net and PSTN lines should still work. It sounds like trixbox/asterisk is refusing connections when it can't get to or resolve a certain external host that is otherwise unrelated to a simple registration of local extensions.

I may have to go with a longer term caching DNS just to prevent this from happening but I still don't understand what the real problem is. The phone says register to 192.168.x.x but it can't? more to this story...

I have found that only those sip trunks that uses the register string (i.e. username:password@voipprovider.com) then the problem occurs. If I disable the trunk that uses register string then it goes away. I have sip trunks that does not use register string and phones work fine with it. So if you are me, I will be searching for VOIP providers that does not require this - most will be voip wholesale providers that usually does not use register string, instead authenticates by your IP address.

Hope this helps.

The bug is specifically in CHAN_SIP.C, and the problem is that when it does a DNS lookup, the lookup function blocks until the DNS server responds. Therefore, if there is a problem with Asterisk talking to DNS, all SIP traffic will halt, timeout, and the whole system will come down like a deck of cards.

If you only use IAX, I don't think you would affected. But if you have any SIP trunks, then everything is affected, included IAX and Zap.

This was reported as early as 2005 and the developer's response was to be a little annoyed with the person who reported it, calling it a such a minor problem...
To me, a small network glitch that brings down the whole system (happens to us several times a month) is something worthy of looking into. But hey, this system still beats my old Panasonic system, I'm not complaining.

Two things I've learned the hard way. Run your own DNS server, and make sure srv_lookups is disabled.

I'm not a big fan of putting band-aids on a system to work around known bugs. I really wish the bug was gone from chan_sip.c. I mean, people have been reporting this for years now. Its not our imagination. If I had the time, I would take a crack at it myself, but I'm starting cold with no experience with the code. I imagine it will take a while for me to get up to speed.

Can't stress this enough. If you do not have srvlookup=no, you are still going to crash, even with a local dns server.
What I found was, Asterisk is constantly doing srv record lookups. When they do not exist, they are not cached. Therefore you will still lockup when dns is down, even if you have a local cache.

Another workaround was suggested to use fixed ip addresses instead of hostnames. But if you do that, what's going to happen when the provider changes an ip address of a server?

I guess someone is looking for a definitive answer to a real problem. Yes, this happen only on SIP channels when the trunk tries to registers then it cannot resolve the SIP provider FQDN to an IP address. Once Internet is down, this will happen immediately if you do not have a local DNS server. If you have a local DNS server with a caching functionality, the problem will occur once the cache is flush-out which will be based on the host TTL value. You can find the TTL value of any FQDN by issuing a command from the console i.e. "dig proxy.sip1trunk.com". TTL values for a fix IP address is long 4 hours or more.

The problem couples when you have a dynamic IP address with your host managed by a dynamic domain registrar. A common scenario is that your dynamic FQDN is resolve via DNS and nothing else that means you did not bind it at you hosts file for some valid reason. Your very own host is SIP server as well as a SIP client. It is a client when registering to your SIP provider. Whatever it will be, it needs to have a properly resolved FQDN to an IP address. TTL value for dynamic host is 60 second, so the most your server can survive is only 60 second with proper local DNS caching. After that it dies.

The concept of swapping configs is not new. This was tested before and it works. This is maybe the only solution for some to have a stable asterisk server when Internet is down. Find below is a modified script that works for me. I am not the original author of this script, I modified it to select very limited configs to be swapped an reload SIP channel only. As I use it with caution pls do. Sample configs are included together with how to run the script.

--start
#!/usr/bin/perl
#/root/icheck.pl v.93 29-Sep-2008

# In the event of internet loss, Asterisk SIP channel doesn't work very
# well. The channel will become very busy registering the trunk to its
# SIP providers that tends to hung-up the server. The SIP registration
# time-out seems forever. This conditions was reported on some users with
# servers behind NAT connection to some SOHO routers.

# Legacy routers may be used instead of this script since users of this
# type are not reporting problem related to DNS resolution such as chan_sip
# freezing.

# How the script works:
# This script will replace the SIP registration files when Internet is down
# with the one with registration entries removed and a hosts file with SIP
# trunks FQDN mapped to a dummy IP addresses. When Internet connectivity is
# restored configs are swapped back. Asterisk SIP module will be reloaded
# every time configs swapping are made. You should run this as a cron job,
# say every five minutes, as well as in system start-up.

# A local caching DNS server is required for uninterrupted SIP Trunk host
# resolution as much as possible. However, for Internet connection with,
# dynamic IP address, your host name FQDN will start to get unresolve IP
# address after 60 seconds when Internet is lost which is the normal TTL
# value of a dynamic IP address. At this time, your system may start to
# fail. The actual system recovery is about 120 seconds after the cron job
# runs this script. If it happens before your host FQDN expires in DNS
# cache, the failover is only 30 seconds.

# Note that SIP trunks FQDN has fix IP addresses and registers longer TTL
# value. A typical SIP trunk host, registers her TTL in a DNS registrar of
# about 4 hours, so a local caching DNS can hold and resolve the IP address
# longer.

# It also mean that with a caching DNS fully functional in your network,
# you still experience a sip_chan freezing problem. To check and ensure
# caching functionality, run a command "dig proxy.siptrunk1.com", you should
# get a value of 5ms less on repeated attempts.

# How to install:
# Copy your sip registrations and hosts file to a temporary file use for
# no internet. Remove all registration entries on sip registrations file.
# Temporary hosts file should contain all SIP Trunks FQDN mapped to dummy
# IP addresses including your very own host dynamic FQDN. If you are
# lucky to have a fix IP address, pls disregard the later.

# Sample hosts file when Internet is UP. Only part is shown of /etc/hosts.
# # SIP Trunks mapped to dummy IP adresses
# # Use this when internet is UP.
# # 127.0.0.1 myhost.dyndomain.com
# # 190.221.62.198 proxy.siptrunk1.com
# # 199.65.166.131 proxy.siptrunk2.com
# # 208.11.192.23 proxy.siptrunk3.com

# Sample hosts file when Internet is Down. Only part is shown of /etc/hosts.
# # SIP Trunks mapped to dummy IP adresses
# # Use this when internet is Down.
# 127.0.0.1 myhost.dyndomain.com
# 190.221.62.198 proxy.siptrunk1.com
# 199.65.166.131 proxy.siptrunk2.com
# 208.11.192.23 proxy.siptrunk3.com

# Sample SIP registrations file when Intenet is UP.
# /etc/asterisk/sip_registrations.conf.
# ; do not edit this file, this is an auto-generated file by freepbx
# ; all modifications must be done from the web gui
# register=1777XXXXXXX:1234b@proxy.siptrunk1.com
# register=1474XXXXXXX:1234b@proxy.siptrunk2.com

# Sample SIP registrations file when Intenet is Down.
# /etc/asterisk/sip_registrations.conf.
# ; This is the temporary SIP registration file to be use when internet
# ; is down. Ensure that no or only commented entries are present.
# ; register=1777XXXXXXX:1234b@proxy.siptrunk1.com
# ; register=1474XXXXXXX:1234b@proxy.siptrunk2.com

# Save these temporary files as bb_no_sipregistrations.conf and bb_no_hosts.
# Then, you may create this script using "vi /root/icheck.pl". Copy all,
# paste and save the new file. Set file permisson to "chmod uog+x
# /root/icheck.pl".

# Run this script in crontab "crontab -e". To test, run "/usr/bin/perl
# /root/icheck.pl" at your console.
# Contab entry:
# */5 * * * * /usr/bin/perl /root/icheck.pl
# Also, in system autoruns "/etc/rc.d/rc.local" to set active configs before
# starting asterisk.
# /usr/bin/perl /root/icheck.pl
# /sbin/fxotune -s
# /usr/sbin/amportal start_fop

# Do not load or reload freePBX web gui SIP Trunks when internet is down
# since it will auto-generate sip_registrations.conf file.

# Forum URL:
# http://trixbox.org/forums/trixbox-forums/open-discussion/asterisk...
# http://www.elastix.org/index.php?option=com_fireboard&Itemid=55&f...
# Or, you may send comments directly to info@icbnsys.com.

use Net::Ping;

my $ip = "216.52.29.100"; # host you want to test for connectivity
# my $ip = "192.168.166.131"; # simulate no-internet connectivity
my $bb_no_sipregistrations = "/etc/asterisk/bb_no_sipregistrations.conf";
my $bb_ok_sipregistrations = "/etc/asterisk/bb_ok_sipregistrations.conf";
my $running_sipregistrations = "/etc/asterisk/sip_registrations.conf";
my $bb_no_hosts = "/etc/bb_no_hosts";
my $bb_ok_hosts = "/etc/bb_ok_hosts";
my $running_hosts = "/etc/hosts";
my $bb_status = 0; # assume Internet is Down
my $wait = 5;
my $reload = "asterisk -rx 'sip reload'"; # reload asterisk SIP configs

$p = Net::Ping->new("icmp"); # use icmp ping to desired destination
if ($p->ping($ip) )
{
# Internet is Up
print "Internet is Up.... ";
$bb_status = 1;
if ((-e $bb_ok_sipregistrations)) # check the default version
# of the config file
{
# Rename active config files to no-internet version
# rename (old name, new name)
# Load default version config files
# rename (old name, new name)

rename($running_sipregistrations,$bb_no_sipregistrations);
rename($bb_ok_sipregistrations,$running_sipregistrations);
rename($running_hosts,$bb_no_hosts);
rename($bb_ok_hosts,$running_hosts);

print "loading default config files\n";
sleep(5); # give time for caching DNS to take over
print "reloading asterisk SIP configs\n";
system("$reload"); # reload asterisk SIP configs
exit;
}
else {
print "No status change\n";
exit;
}
}
else {
print "Internet is Down.... ";
$bb_status = 0;
if ((-e $bb_no_sipregistrations)) # check if it is the
# no-internet version
{
# Rename active config files to default version
# rename (old name, new name)
# Load no-internet version config files
# rename (old name, new name)

rename($running_sipregistrations,$bb_ok_sipregistrations);
rename($bb_no_sipregistrations,$running_sipregistrations);
rename($running_hosts,$bb_ok_hosts);
rename($bb_no_hosts,$running_hosts);

print "loading temporary config files\n";
print "reloading asterisk SIP configs\n";
system("$reload"); # reload asterisk SIP configs
exit;
}
else {
print "No status change\n";
exit;
}
}
--end

Lastly, pls allow me to post my personal comments so some items on this thread.
- using IP address instead of FQDN
The reason that your host use FQDN is to make them possible change their IP address later. The valid one I think is to make them possible set-up a multiple proxy where they can geographically position their servers. How can you use and IP address in this case so it it better don't use IP address directly. Set-up resolution in following order; hosts > cache > DNS.
-- srvlookup=no
The same reason, behind that multiple proxies are poll of SIP servers. It could more than 9 servers behind. If you place your trunk srvlookup=no you lost that change of getting that SIP connection to a nearest and least loaded SIP server.

Thanks,
iCyberNet

The hang-up happens specifically when your SIP trunk sent registration request to your SIP provider waiting for an answer. It does not matters if you have properly resolved host where in your case a direct IP address.

iCyberNet

going out to public DNS that is not resolved on your local DNS server.
For me, it was srv lookups.

The way I found that out was to use EtherReal to watch the traffic going out from the server. I suggest you do the same.

Now you must find out what other lookup is going out. Only a packet trace will tell.

How can this go unacknowledged? It might be a really tough thing to fix, or not, but at least say we believe it is a problem.

Does anyone know of workarounds that are practical? Is a caching DNS server a solution that at least prevents the whole system from going down? Is running only IAX trunks a solution? Being a SOHO my options are very limited.

great, while writing this the boss let me know how livid he is. perception is everything and because of this morning's internet thing he is screaming over the slightest thing. apparently he dropped another important call. I don't see a reason for it this time.

However..... around the same time a strange timezone thing fixed itself. The server and GUI both show the right time but a user complained that a voice mail was time stamped an hour off and after deleting the message the MWI was still showing but no message could be found. Suddenly it went away an hour later and the boss went nuts over a dropped call.

Now I'M pissed.

Perception indeed. I'm even getting nastygrams over things like busy signals. "Perhaps it is just that, busy", isn't good enough for them. I'm dealing with a system that is pretty reliable with great sound quality. However, as we speak the boss has his trusty sidekick (who would be happy with a hand cranked phone and Ernestine the operator) calling Bell and anyone else that can charge us x100 for landlines that we can't get here anyway. been there done that but nobody listens.

I have a good internal DNS (on a CentOS 4.7 server) that every device uses instead of hitting the ISP. The DNS forwards to OpenDNS servers and to each of two ISPs. The firewall routes appropriately depending on where that server is and I split routing to two OpenDNS servers over each WAN. Not getting a DNS answer would be a very rare thing.

The DSL outage this morning lasted less than a few minutes. Barely long enough for failover to happen. The users didn't even notice. But the trixbox did.

I'm going to look at longer caching DNS. If that fixes the dead trix then I'll be a little happier. We can't all have T1s however if one little SIP trunk can kill the whole system then I'll let my neophyte coworkers buy old school crap. This is killing me as it is with a simple dropped call.

Speaking of Iceland, I'm going in a couple of weeks and with my SIP phone I can make calls no differently than being at the office. Works for me but what a pain trying to convince the others that a rare problem is not such a big deal given the savings and flexibility we get.

IcelandDreams,

Here's an idea for you (this is what I do):

1. Run a local DNS server on your internal LAN (sounds like you already do this)
2. Configure your DNS server to be a full-blown DNS server (no forwarders)
3. If your providers have static IP's for the most part, create A-Records for them in your DNS server, so they resolve even in the event of an internet outage.

I use this configuration in two of my offices, and I've never experienced a loss of SIP connectivity due to internet outage (aside from not reaching my providers).
One other item of note, is that I run multiple DNS servers per office, to eliminate the possibility (for the most part) of a server not being available.
I realize that this is not the ideal option, but it allows you to use DNS name resolution on your system, and you should only ever have to manage the IPs in one spot (assuming your have proper replication setup between your DNS servers)

Hope this helps,

-Chris

If they only have a couple of lines, go with a Rhino card, I use the PCI-Express version of their 8 port card and love it. You could also go with a couple of ISDN (BRI) lines to get a digital line (probably less than a T1), or just go with a partial PRI (12 channels or something, though that's not usually affordable). Of course you could also just get a couple of hard-lines and use the rest over SIP, etc... all sorts of possibilities.

-Chris

I'd recommend the following product:

http://www.rhinoequipment.com/R8FXXcard.html

I use the PCI-Express version and love it. This will allow you to continue to use your trixbox system, but use the analog lines for the master's pleasure...

-Chris

I agree that they should go back to dumb analog and evaluate 1987 all over again. No blame on my end for a while. However that too is a pain for me since I just finished converting all the analog lines at the desks to cat5 so the phones run on an isolated switch. Now I would have to switch back. And then the issue of all these new 55i phones. Most of the users love them and have mastered the art of the uber complicated feats such as transfer and 3-way. :)

I am certainly looking at FXO options and if I did I want a good card that simply works. I'll guess that CID will be 1-2 rings slow as it is now with the landlines. I don't yet know exactly what they are getting since the people in charge don't understand it and are terrified of anything digital right now. I'm in a catch-22 world.

fyi, I was also told that besides stopping my pbx work to stop the 'blogs' that I think means I can't even ask you folks for help. Even though for me and most of the crew here the trix has worked very well and saved lots of money in comm costs it has been a total nightmare on my nerves because of one or two. there I've probably just signed my own pink slip. If they happen by here they won't have trouble finding my posts (but can't work a modern phone).

Sorry to hear of your troubles. Restoring confidence is near impossible.

So I am understanding they won't run the analog lines through the trixbox? That's disappointingly.

There are some of us here, me included that believe voice over the public Internet is not ready for prime time. You had a geographical problem that PRI or private SIP services where simply not available.

Hope things work out well for you, keep us posted (on your time)!

Anyone got any news or a awesome fix for this issue.
It seems like kind of a bad issue to have your trixbox loose all it's registrations over loosing the internet connection.
Do you think digium is going to update a patch for this issue or something?
Thanks
Joe

I thought I saw mention of it being fixed in 1.6 on the mailing list, but have searched a few times since and can't find anything to confirm this.

Scott, thanks, but I have a local DNS server.

Here is what happens. I've watched it.

The record for Voicepulse has a 5 minute ttl. For 5 minutes, the cache server gives the address to asterisk.
5 minutes after the connection is lost, the dns server deletes the record from the caching server.

Everything dies.

Honestly, i would use DNS on the asterisk server instead and keep resolv.conf to OpenDNS while the internet is up.

Having srvlookup option in sip_custom won't do anything, it should be either on the top of sip.conf under [general] or a rule for each trunk. If you're internet is out, you could actually put resolv.conf to 127.0.0.1, i've seen that bring the phones online before actually, just make sure you fix it as soon as your internet goes up and /etc/hosts is properly configured.

But this is a 'bug' caused by registering SIP only. If you comment out the register line when your internet goes out, then your phones will all come back online. This is the only temp fix I can think of that actually works when having voip trunks that require registration.

Hi Charles.

Understood, but we don't even know when it goes out. May not be anyone there to make a change anyway.
We just start getting emails from friends asking why they can't call us. Making manual changes everytime there is an internet hiccup wouldn't be an option.

Internet may dropout 3 or 4 times a day for a short time. Maybe 3 in the morning.

I check the log the next day and see the retries....

After thinking this over, I think the ultimate solution is to put all the ip addresses in the HOSTS file. Then have a perl script run every 30 minutes to update the hosts file if a dns address changes.

That should fix it once and for all.

I normally wouldn't post things from other distributions, especially when I spend a fair bit of time on that distribution. However, I believe that there is a need for a greater community involvement on this issue. It affects all popular distributions such as Trixbox CE, Elastix, PIAF as well as many of the lesser known or new ones.

This issue will not resolve itself with a couple of quick posts e.g. tried DNS Cache that it didn't work, tried SRV lookup didn't work. It needs some structure in the testing methodology, and making sure absolutely accurate answers are coming back. It is probably not going to have a magical fix that works for everyone, similar to the fact that the SIP Hang problem/bug does not effect every system. Likewise an understanding of what is happening at the lower level is required to confirm what is actually occuring.

The one thing I can confirm is that there are actually two issues, not just one, and this is part of the reason for providing accurate answers back. I am not saying my work is authoritative, or correct. What I have done is spend close to 30 hours working on the issue, with several test systems, including VM testing and re-testing under a reasonably controlled environment. Combined with Packet sniffing and tracing, I am starting to see some results. Some of the comments I state on the issues, are both from facts and also from posts from others and some assumptions why others may be having different results.

Issue 1:
On some systems, when the Internet goes down, the SIP channel remains live until it goes to re-register. At this point if the DNS (held in cache by Linux) record is still valid (Time to Live - TTL is still in time bounds), then SIP will use that record (naturally the SIP transaction will fail as there is no connection), however SIP is happy it has received a response, and doesn't hang the SIP process.

However, if the TTL of the DNS entry is past its used by date, then it will attempt to make a DNS request to obtain an updated and valid DNS entry. This on some systems appears to fail due to an incorrect DNS response or no response causing the SIP process to hang.

Why do all of the results of various systems vary??? It may come down to the network environment, such as Router type (does it perform a proxy action, does your router proxy action lock when their is no internet connection - note this is not a fault of the router - but actually comes back down to how SIP copes with a DNS lookup), are you using a DNS server already on your Network e.g. you have Microsoft Server/DNS Server running etc etc. What is the TTL that your VSP has on their DNS records, do they keep it as short as 5 mins or 6 hours. Some that use round-robin arrangements, prefer to keep a shorter TTL, so if they lose a server, your SIP DNS lookup, will check again in 5 minutes.

Now we are reasonably convinced that this first issue is a DNS issue (based on evidence with Asterisk systems that use DNS Servers located on the internal network do not suffer). Digium also state this when this issue has been raised before. What may vary is how this DNS Server is implemented. With no disrespect to anyone, the amount of incorrect posts on DNS should be setup, and the amount of misunderstanding of how DNS servers are setup, such as primary servers, secondary servers, authorative servers, DNS Cache Servers and the use of Webmin to set these servers up. Again I am no expert either, and I don't know everything about DNS servers, same as I don't know SIP inside out.

Thats why we need to be sure about how we are reporting this issue, what have we got setup, what VSP are we using, what Trunk Details do we have in Freepbx (no Login/password details please!!), how did we setup a DNS Cache, What router are we using, how did we test the issue, did we do a disconnect and waited 10 mins, do I only have 1 SIP trunk, or 1 SIP trunk and an IAX Trunk. This is the only way that we can start narrowing down the issue.

Issue 2:
Even with the DNS issue correct in Issue 1, there is another issue with SIP connections. This one is a little easier to replicate. Turn your router off, reboot your Asterisk based system, after it has booted, turn your router back on, in many cases, your SIP Channel comes back online.

Test again: Turn your router off, reboot your Asterisk Based system, leave the router off for 5 mins, turn your Asterisk Based system back on, now check you will probably find that your SIP Channel is not coming back online.

This varies between systems, depending on boot speed, router recovery speed, for some they don't have to wait 5 mins, for others it may be a slightly bit longer.

However the SIP Channel never recovers, not 20 mins later, not 2 hours later, not until a SIP reload is performed either manually or via a KLUDGE. This is inappropriate for systems running a phone system. It needs to recover itself. IAX does recover, so why doesn't SIP.

I am still working on the second issue with traces, but initial review is that it appears that after the SIP communications fail, the actual channel chokes. Asterisk appears to send a REGISTER command, and it receives an OPTIONS command, but does not respond to it. Naturally the VSP is waiting for a response, and on the Asterisk end, no response after 32000ms, so it breaksdown the SIP transaction.

As I mentioned, we need to be clear on what tests or situation that it didn't work. We need to be sure what issue we are looking at, as many have felt that this was all the same issue, when in fact it is not.

As I said, we need to be more specific with these posts on this matter. This issue has been round since 2006, and because there is no united, clearly documented, properly tested issue to present to Digium, they are not going to look at the issue.

For those that want to read more on this issue, you can see the long winded posts at
http://www.elastix.org/index.php?option=com_fireboard&Itemid=55&f...

Regards

Bob

I appreciate what you are saying...even more the reason to take a fresh, reasonably structured look at it again and push to get this issue resolved.

The reasons for this are:
1) I had looked at some of the closed issues several months ago, and I have had another look now and cannot find an open issue.
2) Back pre-2006, the amount of users using Asterisk based systems was a lot less than there are now, and the reproducibility, and commonality of the issue was not there. This issue is becoming more prevalent now...
3) The dismissive way that Digium looks at the issue is a little disconcerting. Agreed the issue does not appear to be Asterisk alone, it appears to be the way that gethostbyname works under Linux, but like many applications they have made changes to work around it, and realistically it should be handled at this level
4) The documentation you refer to on this issue is haphazard especially back in those days
5) I fully appreciate that the issue (issue 1) mainly occurs on users using sip_nat.conf/externhost/dynamicip setups, and in a professionals mind you wouldn't setup an Asterisk system with an dynamic DNS setup (I wouldn't) or similar, but as it has been clearly pointed out by Ben, there are many occasions where it is not possible to do this (less developed countries, ISP's that will not provide IP addresses, some cable internet providers, or even if Static IP addresses are available - large costs or required to move to their $400+ per month business grade Internet to get a static IP address.)

As for issue 2, again this is not acceptable, as this occurs on any system (not just the ones mentioned above). A power failure is a real possibility, and to have a system not reconnect to your ISP, because the Internet line had not come up first, and sit there for the next 5+ hours until someone notices can be costly, especially if it falls over to the PSTN links only.

Regards

Bob

double post

Just letting you know that trixbox pro has this issue also.

I am part of the trixbox advisory panel (T.A.P.) for the trixbox pro product and have sent the link to this post to the head engineers at Fonality and the Customer Support manager. I will let you know what happens with my inquiry to Fonality on this matter.

Don't let this minor setback be an issue,
was it such a huge issue, lots of us, wouldn't have been using Asterisk, and Digium, would have already fix the problem

Taking note that your have 10PSTN lines, i think most of your outbound will be via the PSTN, with "limited" internet traffic.

If however u are going to have an Internet trunk, see a VISP that provides IAX terminations..
and you are all good to go, won't have issues with this probelm

there is another Distro, that claims, they have this problem solved with dns caching..

But go for the project, and don't be discourage

sidi

I should qualify that with: for me, using Voicepulse as my service provider, with a TTL of 5 minutes, my system goes down in less than 5 minutes. Usually in under 60 seconds. Whatever is remaining in the TTL after the connection drops.

I'm having good luck so far with hard coded IP addresses, and I may write that automatic update script sometime when I have free time.

Reading this thread leaves me confused. I have deployed a system at a camp where we only have 2 pots lines and no internt. I haven't had any issues like this the system has remained up for about a year. Is this because the issue only raises if the system is trying to resolve a host?

Not so; it is only an issue for some folks due to their setup

I use SIP trunks and NEVER have had this issue unless I created it.

I have dozens of boxes using sip with PSTN failover and this has never been reported to me.

Some boxes have IAX trunks to other boxes, and most have Nagios installed for monitoring the boxes.
As for as I know most sites a running a local DNS (caching only for some with AD on the network)
Phones are Polycoms with a few Ciscos and Grandstream junkers (throw away phones for the hash workspace of factory)

My two providers of which one is setup on all the boxes
Vitelity and Voicepulse.... Vitelity reconnects a little faster than VP in most cases.
some have zaptel devices
some run other programs / apps which are accessed from outside.

Hardcoded IP's and srvlookup=no works perfect for me. Of course you are giving up the flexibility of DNS, but at least you never have to worry about the SIP stack issue.

If you use only ip address for registration and trunks do not install dns server on TB just change resolv.conf file as

[trixbox1.localdomain bin]# more /etc/resolv.conf
nameserver localhost

Regards,
Alen

We will just have to wait and see what Fonality comes up with as a permanent fix.