Hi, Tony. Thanks for your fast answer. I tested with dig to see if it finds the records. Yes it finds them, but from time to time dig does not find the records. This is the time when sipxecs sends the alarm.
We don't have started bind on this machine. Our DNS servers are in other machines. I checked /etc/host.conf and order is ok: order hosts,bind The interesting is that this problem happened also after i added the entries to /etc/hosts. Yes, when we add entry to /etc/hosts we don't need to restart network services. Hmm, yes, we thought to use something like fake zone for this ITSP and to tune little bit settings in sipxecs. Will be a solution if we run a caching DNS server on that machine? On Mon, 2010-01-11 at 08:52 -0500, Tony Graziano wrote: > First, can you do a dig from the CLI of the system to verify it can't > find the record? > > > Example using a different nameserver: dig @ns1.google.com > www.google.com > > > Did you restart named service (bind)? The lookup is handled by the > order in your network (hosts, dns), is the standard order. If you stop > bind does it still resolve/lookup via the hosts file? I don't believe > adding a host entry would require a network service restart, but the > above test would indicate if your system is properly looking it up via > the hosts entry. > > > I had an issue like this with an ITSP I had to disassociate with > because of their woeful network. Ultimately, I found that I had to > create a fake zone for their domain on my system in order to get > registered properly, but there is not telling what else that would > break, so it is not something I would recommend. > > > You should also look at the advanced settings of the registration > interval. Devices>Gateways>choose_the_itsp_gateway>ITSP > Account>advanced>Registration Interval. > > > If the default is "600", you might "adjust" this to force an earlier > re-registration. > > > > > On Mon, Jan 11, 2010 at 8:37 AM, [email protected] > <[email protected]> wrote: > Hi, > > we are experience a problem with ITSP registration. We receive > the > following report: > > Message from sipXecs > Alarm: SPX00022 > Reported on: sipxecsserver.domain.tld > Reported at: 2010-01-11T13:06:13.829583Z > Severity: INFO > Alarm Text: An ITSP 'sip.voicetrading.com' was not configured > correctly. > The SIP Trunking service could not Register with it. > Suggested Resolution: Check your Domain, Proxy and Registrar > settings > for the ITSP account. > > Some times ot recover after minute, but sometimes after 5-6 > sipx > minutes. > > I see in the sipxbridge.log that system cannot find A record > for ITSP > domain: > > 2010-01-11T13:06:13.811000Z":1909:JAVA:WARNING:asgard.iguanait.com:Timer-0:00000000:SipUtilities:"FindSipServer::findServer > Unable to resolve by A sip.voicetrading.com" > > I tried to add IPs and sip.voicetrading.com to /etc/hosts, but > didn't > helped. > > What is the best solution for this situation? > > Thanks in advanced! > > _______________________________________________ > sipx-users mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: > http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > Fax: 434.984.8431 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > Why do mathematicians always confuse Halloween and Christmas? > Because 31 Oct = 25 Dec. > > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
