I've had this problem too. It would get so bad, that it wouldn't even answer incoming calls, and if I tried to dial out via pstn, I would have hung up before it got around to dialing (which it would eventually do, unfortunately).
A short-short term solution was to install bind, and use it as your primary nameserver. Hopefully it'll cache dns queries long enough to survive an outage. A slightly better (in my opinion) solution would be to code a pure caching dns server, whose sole purpose is to look up specific domains and resolve them to their ip address. It'll record the result, and will check every so often (once a minute, hour, day, whatever) and update its results. If it cannot get an answer, it keeps using the last known ip address. If anyone knows of a really bare-bones, standards-breaking dns server that would say, check a flat file database each time a request is made, we could run a daemon that would check the domains we need to resolve; if no answer is received, we just skip that line. That way the daemon will be sitting there waiting for a dns answer, and not asterisk. The best solution would be to "fix" asterisk (I say "fix", as I'm sure many will say it's not broken, that's fine). If your internet connection fails, there's no reason to have internal calls and calls in and out of your pstn lines failing too. Personally, I have a toll-free line that runs over voip, and if it can't reach my server, it'll fall back and dial a landline I have. In this case though, if my internet connection is down for an extended period of time, even those calls won't make it through. Joseph Tanner On 4/11/06, picciuX <[EMAIL PROTECTED]> wrote: > > because, a this time, the sip stack doesn't have asynchronous DNS... so ALL > the sip code is stucked waiting timeouts for DNS queries (that are long > timeouts). > When you try to dial a LAN device, the sip code is trying to resolve your > voISP service providers' addresses. > We workaround this putting all external sip peers in a separate file, say > "sip_peers.conf", included in sip.conf with "#include filename". > Then, a daemon on the box try to resolve well-known addresses on well-known > DNS servers on the net, every 5 minutes. If the demon fails ALL the > well-known DNS queries, it assumes no internet connection is available: then > it renames sip_peers.conf, and ask asterisk a "sip reload". So all external > sip references are out, and sip still continue working for internal phones. > Needless to say, when connection come up again, the daemon do the opposite > thing. > > hope this helps > > > 2006/4/11, Brent Torrenga <[EMAIL PROTECTED]>: > > Out internet connection was out this morning. It seems that the SIP > > extensions on our LAN were affected. Behavior like: > > > > Call comes in over POTS to a TDM400P, there is a delay then before the > Cisco > > 79[46]0's start to ring. > > If we were lucky enough to get a call through, then we could not transfer > > the call, or place the call on hold, or park the call. > > Outbound calls seemed to have a delay between the time they were dialed at > > the SIP phone and when they were connected. > > > > I know this has been brought up before, in fact there is a bit of a > > discussion going on now about DNS SRV (in sip.conf, set srvlookup=no, or > put > > all the phone ip's on /etc/hosts). But what is really causing the issue > > here? Yes, it is DNS, or something related to DNS, but why does that have > > anything to do with * trying to make a phone ring on the LAN? > > > > I would think that by using qualify=yes for any outbound voip trunks we > > avoid an issue of trying to call out is the net is down, but why are any > > operations on the LAN affected? > > > > > > Sincerely, > > > > Brent A. Torrenga > > [EMAIL PROTECTED] > > > > Torrenga Engineering, Inc. > > 907 Ridge Road > > Munster, Indiana 46321-1771 > > > > +1 219 836 8918 x325 Voice > > +1 219 836 1138 Facsimile > > www.torrenga.com > > > > _______________________________________________ > > --Bandwidth and Colocation provided by Easynews.com -- > > > > Asterisk-Users mailing list > > To UNSUBSCRIBE or update options visit: > > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
