Could Monit do it? I am playing with it now!

Regards
Michael Knill

-----Original Message-----
From: Michael Keuter <li...@mksolutions.info>
Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
Date: Thursday, 8 June 2017 at 8:58 pm
To: AstLinux List <astlinux-users@lists.sourceforge.net>
Subject: Re: [Astlinux-users] Problems with losing SIP Trunk


> Am 08.06.2017 um 10:28 schrieb Michael Knill 
> <michael.kn...@ipcsolutions.com.au>:
> 
> Ah so have you had similar problems to me then where Asterisk has still lost 
> connectivity when PPPoE comes back?
> Do you know why it does this?
> 
> Regards
> Michael Knill

No not really, I just let the cron script run so that the ISP disconnect does 
not occur during office time.

It would be nice if this could be monitored somehow and then action could be 
taken automatically (like with DynDNS).

> -----Original Message-----
> From: Michael Keuter <li...@mksolutions.info>
> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
> Date: Thursday, 8 June 2017 at 6:24 pm
> To: AstLinux List <astlinux-users@lists.sourceforge.net>
> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk
> 
> 
>> Am 08.06.2017 um 09:51 schrieb Michael Knill 
>> <michael.kn...@ipcsolutions.com.au>:
>> 
>> 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
> 
> What I do at PPPoE sites is a cronjob that restarts PPPoE at 03:00, waits an 
> amount of time (20-180 seconds, needs to be tested) and then restarts DNS and 
> reloads Asterisk (whatever you need).
> Usually the ISPs disconnect the DSL lines every 24 hours (at least here in 
> Germany).
> 
>> 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
> 
> Michael

Michael

http://www.mksolutions.info




------------------------------------------------------------------------------
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.


------------------------------------------------------------------------------
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.

Reply via email to