> Am 12.02.2018 um 10:46 schrieb Michael Knill
> <michael.kn...@ipcsolutions.com.au>:
>
> Hi All
>
> Just though I would give some feedback on my testing. It appears to be all
> working in the lab:
>
> Script
> --------
> #!/bin/sh -e
> SHOW_TRUNKS="$(asterisk -x 'sip show peers' | grep $1)"
> if [[ $SHOW_TRUNKS != *"Unspecified"* ]] && [[ $SHOW_TRUNKS = *"UNKNOWN"* ]];
> then
> echo "Trunk needs a reload"
> exit 1
> else
> echo "Trunk is normal"
> exit 0
> fi
>
> Monit Config
> -----------------
> check program Trunk-Monitor
> path /mnt/kd/scripts/trunk_monitor eict_trunk
> if status = 1 for 3 cycles then exec "/usr/sbin/asterisk -x 'module reload
> chan_sip.so'"
>
> Output Logs
> -----------------
> After outage with dnsmgr recovering the trunk ip address:
> sip show peers ->
> eict_trunk/0290010593 210.0.113.21 Yes
> Yes 5060 UNKNOWN
>
> Monit does its thing:
> Feb 12 20:31:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor'
> status failed (1) -- Trunk needs a reload
> Feb 12 20:32:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor'
> status failed (1) -- Trunk needs a reload
> Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.err monit[30658]: 'Trunk-Monitor'
> status failed (1) -- Trunk needs a reload
> Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor'
> exec: '/usr/sbin/asterisk -x module reload chan_sip.so'
> Feb 12 20:33:17 3999-IBCBuild-CM1 local0.notice asterisk[30844]:
> NOTICE[30883]: chan_sip.c:24586 in handle_response_peerpoke: Peer
> 'eict_trunk' is now Reachable. (55ms / 5000ms)
> Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtp:
> host=smtp.ipcsolutions.com.au tls=on auth=on ......
> Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtpqueue: Success:
> /var/spool/mail/2018-02-12-20.33.16-0.msmtp
> Feb 12 20:35:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor'
> status succeeded (0) -- Trunk is normal
> Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtp:
> host=smtp.ipcsolutions.com.au tls=on auth=on .......
> Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtpqueue: Success:
> /var/spool/mail/2018-02-12-20.35.16-0.msmtp
>
> sip show peers ->
> eict_trunk/0290010593 210.0.113.21 Yes
> Yes 5060 OK (55 ms)
>
> I will now need to see how it works in the real world.
> Yay Monit!
Hi Michael,
in my problem cases I also tried reloading chan_sip and restarting Asterisk,
but only a reboot of the system worked for me.
So good luck.
> Regards
> Michael Knill
> From: Michael Knill <michael.kn...@ipcsolutions.com.au>
> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
> Date: Friday, 9 February 2018 at 9:30 am
> To: AstLinux List <astlinux-users@lists.sourceforge.net>
> Subject: Re: [Astlinux-users] Network connectivity and DNS issues
>
> Thanks Michael yes that's my plan ☺
>
> Regards
> Michael Knill
> From: Michael Keuter <li...@mksolutions.info>
> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
> Date: Friday, 9 February 2018 at 8:56 am
> To: AstLinux List <astlinux-users@lists.sourceforge.net>
> Subject: Re: [Astlinux-users] Network connectivity and DNS issues
>
>
> Am 08.02.2018 um 22:04 schrieb Michael Knill
> <michael.kn...@ipcsolutions.com.au>:
>
> Thanks Lonnie
>
> I will give Monit a try and let you know how I go.
> I will only turn on for some sites.
>
> Regards
> Michael Knill
>
> Hi Michael,
>
> in Monit you can run your own programs/scripts and then react on the
> return/exit value of that program. E.g.
>
> ----
> check program CPU-0_Temp with path "/mnt/kd/bin/monit/sensors_temp.sh 'Core
> 0'"
> if status > 70 then alert
> ----
>
>
>
> On 9/2/18, 2:49 am, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote:
>
> Michael,
>
>
>
> So my questions are:
> 1) What frequency of registrations or SIP OPTIONS are actually required to
> keep the firewall translation is place
>
> Depends on the network hardware in the path and the shortest firewall UDP
> TTL setting, AstLinux defaults to a 180 second UDP TTL for
> netfilter.ip_conntrack_udp_timeout_stream states.
>
> By default, in sip.conf, qualifyfreq=60 which sends SIP OPTIONS every 60
> seconds. This should work for most situations.
>
> But, it seems in your situation the transient case with network issues can
> cause problems. Possibly setting qualify to something large like 64000 ms,
> qualify=64000 would enable the qualify feature but would not normally fail.
> Possibly mixed with qualifyfreq=30 . Warning, I have never tested or tried
> this.
>
>
>
>
> 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk
> peer has a Host IP Address but is a Status of UNKNOWN then do a 'module
> reload chan_sip.so' and report it?
>
> Personally I don't use Monit, but in theory it may be possible.
>
> Lonnie
>
>
>
> On Feb 8, 2018, at 12:54 AM, Michael Knill
> <michael.kn...@ipcsolutions.com.au> wrote:
>
>
>
> Sorry all I am dredging up this thread again. Thanks Lonnie for the info
> below.
> Although my main provider uses an IP Address based trunk which makes this
> problem go away, I have some providers that require registration via a DNS
> name.
> I have now activated dnsmgr which is good in that it will update the IP
> Address on the peer so it can reregister, HOWEVER the OPTIONS pings will not
> start up again if down after a reboot.
> I can turn off SIP OPTIONS (qualify=no) and put in a specific firewall rule I
> suppose but I would still rather have qualify=yes
>
> So my questions are:
> 1) What frequency of registrations or SIP OPTIONS are actually required to
> keep the firewall translation is place
> 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk
> peer has a Host IP Address but is a Status of UNKNOWN then do a 'module
> reload chan_sip.so' and report it?
>
> Thanks all.
>
> Regards
> Michael Knill
>
> On 13/1/18, 6:38 am, "Michael Knill" <michael.kn...@ipcsolutions.com.au>
> wrote:
>
> Thanks Lonnie
>
> I have confirmed with my main provider that their IP Address will likely
> never change to I will be putting the IP Address in sip.conf so I don't even
> need to set a static host.
> I do like to know the reachability of my trunks so I will keep the OPTIONS
> pings going.
>
> Thanks so much again for your help.
>
> Regards
> Michael Knill
>
> On 13/1/18, 2:42 am, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote:
>
> Hi Michael,
>
> The easiest way to always make sure a DNS name resolves is to define
> static IP addresses in:
>
> Network tab -> Network Services: -> DNS Forwarder & DHCP Server: {
> Configure DNS Hosts }
>
> There you can statically define DNS host names without requiring any
> changes to your Asterisk configuration. Of course if your SIP provider makes
> changes you will have to reconfigure the DNS IP's like a bunny.
>
>
> Another approach, or in tandem, is to not depend on OPTIONS pings
> (qualify=yes) to keep firewall ports open, instead (qualify=no) use very
> specific (secure) firewall rules for inbound SIP calls.
>
>
> To be clear, it is not recommended to do either of the above as a
> general practice, but you do what you have to do.
>
> Lonnie
>
>
> On Jan 11, 2018, at 10:50 PM, Michael Knill
> <michael.kn...@ipcsolutions.com.au> wrote:
>
>
>
> Hi Group
>
> I have started a new thread although this is a continuation of my
> intermittent issues with sip trunks not coming back after a network outage.
> After some testing in the lab I have realised that most of these problems are
> related to DNS resolution.
>
> Basically I am using sip domain names for all my providers so DNS resolution
> is necessary. What I have found is that if for some reason DNS resolution is
> not possible (e.g. network is down), if the system is rebooted or Asterisk
> loses the resolved address, it no longer sends the OPTIONS pings as it cant
> find the address obviously.
> Yes that makes sense however the problem arises when the network is restored,
> Asterisk is completely unaware and therefore makes no attempt in resolving
> the address.
> I believe this is what is causing my intermittent issues which is easily
> resolved by doing an Asterisk Reload when network connectivity is restored. I
> have also enabled the Asterisk dnsmgr which does not fix the problem. I
> suspect that if it couldn't initially resolve it then it gives up totally.
>
> So what is the fix. Here are some of my options:
> • Don't use DNS but just use the IP Address instead. This will most certainly
> resolve the issue but is it the best way? Something in the Hosts file maybe?
> • Perform sip monitoring using the SIP Monitor script or Monit. If the SIP
> URL is resolvable but the status is UNKNOWN then issue a module reload of
> chan_sip
> • Something else
>
> PS the SIP Monitor does not seem to work for me. It only sends me an email
> when the system is rebooted.
> Thanks all.
>
> Regards
> Michael Knill
>
> Michael
>
> http://www.mksolutions.info
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.
