asterisk users - May 2017 - Need to restart Asterisk if remote server not working?

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 at lucabert.de)

On Saturday 06 May 2017 at 08:37:39, Luca Bertoncello wrote:
> 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...
What was Asterisk doing until you restarted it?  What happened when it tried 
to use the (stale, but now restored) connection?
> 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?
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.

-- 
"Remember: the S in IoT stands for Security."

 - Jan-Piet Mens

                                                   Please reply to the list;
                                                         please *don't* CC
me.

Antony Stone <Antony.Stone at asterisk.open.source.it> schrieb:
> What was Asterisk doing until you restarted it?  What happened when it
> tried to use the (stale, but now restored) connection?
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 at pbxluca' timed out, trying again (Attempt #1769)
> > 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?
> 
> 1. How is your Asterisk server connecting to Deutsche Telekom (SIP, IAX2, 
> other...)?
SIP
> 2. How do you authenticate on that connection (password, certificate, IP 
> address...)?
Password
> 3. Do you connect to an IP address at Telekom, or to a hostname?
Hostname: tel.t-online.de
> 4. Did the IP address of Telekom's end of the connection change?
I really don't know, but I suppose not
> 5. Did the IP address of your end of the connection change?
No.

Thanks
Luca Bertoncello
(lucabert at lucabert.de)

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:
> 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 at lucabert.de)
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20170506/30b7d4a6/attachment.pgp>

Max Grobecker <max.grobecker at ml.grobecker.info> schrieb:

Hello Max,
> I'm also a customer of the DTAG.
> Yesterday, the messed a bit with their DNS entries...
Maybe they tried again to repair a working system... :)
> 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.
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...
> 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 ;-)
Could you say me how can I disable the SRV lookups?
I use Asterisk 1.8.30.0 on an OpenWRT device.
> You should also use the dnsmgr of Asterisk, resp. configuring it to
> reasonable values. In dnsmgr.conf I set:
The version of Asterisk on my OpenWRT unfortunately does not support dnsmgr...

Thanks
Luca Bertoncello
(lucabert at lucabert.de)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digitale Signatur von OpenPGP
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20170506/eb030654/attachment.pgp>