Slightly different but this happened again today. It was a registered trunk but
I had to reload before it worked.
Im beginning to think it's something to do with PPPoE/firewall. I have never
had this problem at non PPPoE sites.
Regards
Michael Knill
From: Michael Knill <michael.kn...@ipcsolutions.com.au>
Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
Date: Wednesday, 7 June 2017 at 11:30 am
To: AstLinux List <astlinux-users@lists.sourceforge.net>
Subject: Re: [Astlinux-users] Problems with losing SIP Trunk
And its happened again at another site. Astlinux rebooted this time which I
hope was a power failure.
It just seems like Asterisk doesn't know that its up. Any ideas on how I should
test this when it happens again? DNS issue maybe?
I might also try sip qualify peer from the cli to see if this brings it up.
Regards
Michael Knill
From: Michael Knill <michael.kn...@ipcsolutions.com.au>
Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
Date: Monday, 5 June 2017 at 11:26 am
To: AstLinux List <astlinux-users@lists.sourceforge.net>
Subject: [Astlinux-users] Problems with losing SIP Trunk
Hi group
I have actually reported this problem before but it was using a different
network connection.
Im on Astlinux 1.2.8 with a SIP Trunk e.g. not registered. This site is via a
firewall so it is using NAT but I don't think it should matter.
It appears that when there is a particular event that there is a temporary loss
of connectivity, but not a link down event, qualify or SIP OPTIONS pings do not
make it to the trunk provider (or back again as I have not been able to test).
Performing an Asterisk reload fixes the problem immediately.
Before reload:
I managed to check the reload before and after firewall states:
Source Port (#'s) Destination Port Protocol
Packets Bytes TTL
192.168.2.5 5060 192.168.2.38 5060 UDP 28535
16835829 2:59
192.168.2.5 5060 192.168.2.39 5060 UDP 17450
10280235 2:58
192.168.2.5 5060 192.168.2.35 5060 UDP 16930
9948145 2:59
192.168.2.5 5060 192.168.2.42 5060 UDP 12961
7604592 2:54
192.168.2.5 5060 192.168.2.37 5060 UDP 3561
2019123 2:57
192.168.2.5 5060 192.168.2.36 5060 UDP 3454
1952748 2:53
124.171.212.155 50133 172.30.10.2 7123 TCP
222 56430 7199:59
192.168.2.22 17500 192.168.2.255 17500 UDP 200
45600 0:55
192.168.2.22 17500 255.255.255.255 17500 UDP
100 22800 0:55
192.168.2.30 138 192.168.2.255 138 UDP 1
229 0:58
172.30.10.2 8272 (10) 8.8.8.8 53 UDP 2
211 0:59
172.30.10.2 56406 (2) 113.20.24.94 10051 TCP
2 120 1:11
48 Total Firewall States
After reload:
Source Port (#'s) Destination Port Protocol
Packets Bytes TTL
192.168.2.5 5060 192.168.2.38 5060 UDP 28773
16975982 2:57
192.168.2.5 5060 192.168.2.35 5060 UDP 17821
10475864 2:59
192.168.2.5 5060 192.168.2.39 5060 UDP 17596
10365993 2:58
192.168.2.5 5060 192.168.2.42 5060 UDP 13069
7667552 2:50
192.168.2.5 5060 192.168.2.37 5060 UDP 3591
2035954 2:50
192.168.2.5 5060 192.168.2.36 5060 UDP 3484
1969553 2:58
124.171.212.155 50133 172.30.10.2 7123 TCP
548 132258 7199:59
192.168.2.22 17500 192.168.2.255 17500 UDP 214
48792 0:43
192.168.2.22 17500 255.255.255.255 17500 UDP
107 24396 0:43
172.30.10.2 5060 125.213.162.112 5060 UDP
2 1042 0:50
172.30.10.2 31249 (3) 8.8.8.8 53 UDP 2
211 0:59
172.30.10.2 56424 (2) 113.20.24.94 10051 TCP
2 120 1:39
28 Total Firewall States
My provider 125.213.162.112 is now there so I assume that the problem is not in
the firewall that Astlinux traverses but the Astlinux firewall itself.
I am sending OPTIONS pings every 30 seconds. Why would this not just set up the
firewall state again? Maybe its an Asterisk problem?
Any ideas? What should I check when it happens again?
Regards
Michael Knill
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
