Multiple invocations of Shellcmd with type afterfilterchangeshellcmd
-
Not directly from shellcmd there isn't.
You're logging into the telephony server and restarting it from pfSense?
Steve
-
@stephenw10
No, pfSense is running the Asterisk server, but that's not my problem. The service provider has a registry expiry time of 7200 seconds, which Asterisk honors, and that leads to long times of unavailability. This is why I want to explicity reregister, when the IP changes.While describing the script that gets called I detected a stupid programming error, which likely caused my problem...
In case it was not so, I'll get back.
-
@jsphgttgns said in Multiple invocations of Shellcmd with type afterfilterchangeshellcmd:
pfSense is running the Asterisk server
Hmm, is that a very old pfSense version? Or a custom install using FreeBSD packages?
Neither is recommend.
Steve
-
@stephenw10
Brandnew: 2.4.4-RELEASE-p3 (amd64)I am of course using FreeBSD packages, and I know that life is a lot easier with the PBX either in LAN, which at most requires in some cases to have some static ports for outbound NAT connections, or on some cloud. The integrated Asterisk server (though reduced to a minimum at runtime) is simply popular...
I'll watch my update afterfilterchanged tonight and I'll see whether my problem will be gone. Meanwhile I've setup another server without *, where I can check things to exclude that my Asterisk adventure is responsible (which I think it is).
-
Ah well that's better then running 2.1.X to keep the old Asterisk package.
Unbelievably there are still people doing that...Steve
-
@stephenw10
The old pfSense Asterisk package doesn't work with well with modern external lines and trunks that require NAPTR and SRV lookups. Asterisk itself is never the problem (unless misconfigured). If I am not allowed to use the router, maybe I should try to find some space in one of the IoT devices, like the one of the refrigerator,
.A good reason to hide the PBX (without a GUI) in the router is to have a stable environment that nobody else dares to touch. Your technical arguments are negligible compared to "children playing."
-
@jsphgttgns said in Multiple invocations of Shellcmd with type afterfilterchangeshellcmd:
one of the IoT devices, like the one of the refrigerator
Ha, I'd like to see that.
Steve
-
@stephenw10
Could it be that all packges are also reloaded when the filters change? If so, I also have a Asterisk script in /usr/local/etc/rc.d.(If one has something that is a little better then Espressif's ESP32 SOC, one could probably get a simple SIP stack to run on it.)
-
Yes a lot of packages are restarted in some situation though I wouldn't normally expect that just from a filter change. If the WAN IP changes for example many packages need to be restarted.
Yes you probably could just run it in a RasPi or similar.... which would get around this issue.
Steve
-
@stephenw10
A RasPi is too big and you'd had to buy it....My point was that if refrigerators or light bulbs had something like a better ESP32 SOC (which they don't have), one could hide the PBX there. In case of a broken fridge or bulb, this would also lead to service calls for the service provider's hotline. I wonder if they would figure out, when the customer says, that whenever the light bulb is defect, my telephone doesn't work, too (unless you inform your family members or friends, which you wouldn't do).
The ISP restarts the PPPoE connection every 24 hours, this is why I came up with the Shellcmd script of type after...
This may actually not be necessary, if I control how Asterisk gets restartet. I need to look at the details, but the Asterisk start script in /usr/local/etc/rc.d also seems to get repeatedly called within a short interval, which likely lead to the race conditions I sometimes observerd (lot's of network errors). Since the Shellcmd script at first cleaned up the entire runtime environment of Asterisk, my problem seemed to be solved.
The only thing I probably need to do is making sure that Asterisk does not get started within a too short interval and that at first the old daemon gets properly killed, i.e. basically my Shellcmd script as the start option of the rc.d script. I always wondered why safe_asterisk was so bulky---there's probably something similar inside the script.
