Need To Restart Asterisk If Remote Server Not Working?

Home » Asterisk Users » Need To Restart Asterisk If Remote Server Not Working?
Asterisk Users 7 Comments

Hi list!

Yesterday Deutsche Telekom had a really big problem and Asterisk couldn’t connect to the remote Server (by Telekom) until today about 7:30.

Well, it could happen… What I find really annoying was that I needed to restart Asterisk as I
checked with sipsak that the Telekom-Server works…

I think, this should not be normal… Can someone explain me why it happens and what I have to change in the configuration to avoid this problem?

Thanks a lot Luca Bertoncello
(lucabert@lucabert.de)

7 thoughts on - Need To Restart Asterisk If Remote Server Not Working?

  • What was Asterisk doing until you restarted it? What happened when it tried to use the (stale, but now restored) connection?

    1. How is your Asterisk server connecting to Deutsche Telekom (SIP, IAX2, other…)?

    2. How do you authenticate on that connection (password, certificate, IP
    address…)?

    3. Do you connect to an IP address at Telekom, or to a hostname?

    4. Did the IP address of Telekom’s end of the connection change?

    5. Did the IP address of your end of the connection change?

    Antony.

  • Antony Stone schrieb:

    Just saying, that it was not possible to connect to the remote server…

    [May 6 07:26:50] NOTICE[3376] chan_sip.c: — Registration for
    ‘03514977290@pbxluca’ timed out, trying again (Attempt #1769)

    SIP

    Password

    Hostname: tel.t-online.de

    I really don’t know, but I suppose not

    No.

    Thanks Luca Bertoncello
    (lucabert@lucabert.de)

  • I suspect this may in fact have been the cause of your problem.

    Firstly, I notice that tel.t-online.de has a non-trivial DNS entry:

    $ host tel.t-online.de tel.t-online.de is an alias for ims.voip.t-ipnet.de. ims.voip.t-ipnet.de is an alias for ims001.voip.t-ipnet.de. ims001.voip.t-ipnet.de is an alias for b-epp-001.isp.t-ipnet.de. b-epp-001.isp.t-ipnet.de has address 217.0.18.36

    Secondly I find forum entries from people observing that either the IP address changes from time to time, or even that Telekom’s DNS servers do not give the same result as root name servers:

    https://telekomhilft.telekom.de/t5/Telefonie-Internet/IP-Adressbereich-tel-t-
    online-de/td-p/2325114

    https://telekomhilft.telekom.de/t5/Festnetz-Internet/VoIP-Telefonie-DNS-
    Aufloesung-von-tel-t-online-de/td-p/1563089

    Certainly, with allth eother information you gave, if the IP addresses at both ends stayed the same, I wouldn’t expect an Asterisk restart to be necessary.

    Regards,

    Antony.

  • –3u7EIrAs23dAqekRI9G4AEcgllh8bj4jA
    Content-Type: text/plain; charset=iso-8859-15
    Content-Language: de-DE
    Content-Transfer-Encoding: quoted-printable

    Hello,

    I’m also a customer of the DTAG. Yesterday, the messed a bit with their DNS entries…

    If you are NOT using their DNS resolvers you got a “wrong” IP address back that was not working. Besides that, you should disable SRV lookups for their SIP peers. Since Asterisk’s chan_sip.c does not honour the weight of the SRV entries, nor it failovers to the other records, you might just end up with a not working server. PJSIP might work with that, but it depends on your version.

    The “blank” A record for “tel.t-online.de” is also provided and will be changed in case of service disruptions on one server, so it’s acceptable to rely on that.

    DTAG is providing the following SIP servers at the moment (and also yesterday) with their SRV records:

    _sip._udp.tel.t-online.de. 401 IN SRV 0 5 5060 ims001.voip.t-ipnet.de.
    _sip._udp.tel.t-online.de. 401 IN SRV 1 5 5060 ims002.voip.t-ipnet.de.

    ims001 should be the preferred one based on the SRV weight. But Asterisk only looks at the first record that comes as an answer, so if ims002 is at the first position it will be used for registration, regardless that the other record is weighted better. And if that one is not answering… So: Better disable SRV lookups if you are not sure if your SIP channel driver supports it 😉

    You should also use the dnsmgr of Asterisk, resp. configuring it to reasonable values. In dnsmgr.conf I set:

    enable = yes refreshinterval = 10

    If dnsmgr is not enabled on your server this might have caused the problem because your SIP driver did not recognized that the target address of the configured hosts has changed. DNS changes should work also without dnsmgr – but since I’ve enabled the dnsmgr I had far less problems with changing DNS records 😉

    Am 06.05.2017 um 09:37 schrieb Luca Bertoncello:

    –3u7EIrAs23dAqekRI9G4AEcgllh8bj4jA

  • Max Grobecker schrieb:

    Hello Max,

    Maybe they tried again to repair a working system… 🙂

    I’m running an own BIND on my Linux-PC… Maybe should I configure a forwarder for the zone t-online.de? It not difficult, and if you mean it can help, I’ll do that…

    Could you say me how can I disable the SRV lookups?
    I use Asterisk 1.8.30.0 on an OpenWRT device.

    The version of Asterisk on my OpenWRT unfortunately does not support dnsmgr…

    Thanks Luca Bertoncello
    (lucabert@lucabert.de)

  • –HeOcG0map64nxPXdTtqbrlsnQMrBSMdgW
    Content-Type: text/plain; charset=windows-1252
    Content-Language: de-DE
    Content-Transfer-Encoding: quoted-printable

    Hi Luca,

    Am 06.05.2017 um 15:49 schrieb Luca Bertoncello:

    Me too 😉

    In the meantime, I setup forwarding requests to “t-online.de” and “t-ipnet.de” to the address 194.25.2.129. That is kind of a global DNS resolver for all customers and is working since the 90s without address changes.

    In your sip.conf, simply add

    srvlookup = no

    To your DTAG peer configuration. If set globally, you may break the ability to directly call SIP addresses.

    On embedded systems, I often had problems with “stuck” DNS. But that was ages ago… The last time on my old “Horstbox” with Asterisk 1.2 and bristuff on Linux 2.4 :-/

    Have you rebooted the whole WRT device or just restarted the Asterisk service to resolve your problem?
    Maybe it’s less an Asterisk issue but one with DNS caching on this device?

    Viele Gr

  • Max Grobecker schrieb:

    OK, I’ll set it up now… 😉

    I see now, that I already have this globally set…

    I just restarted Asterisk…

    Thanks Luca Bertoncello
    (lucabert@lucabert.de)