No sorry Michael. I have the new release out now and I will be progressively
rolling it out. By default its not on as most of my sites use an IP Address
hostname so its not necessary.
I think its going to be a while before it can prove itself but I will let you
know.
It worked fine in the Lab as you can see below so I have no reason to believe
that it wont work in production.
Regards
Michael Knill
On 21/2/18, 3:43 am, "Michael Keuter" <li...@mksolutions.info> wrote:
> 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!
>
> Regards
> Michael Knill
Any real world experiences yet?
> 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
------------------------------------------------------------------------------
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.
