Asterisk 1.8 package
-
1/ You do NOT make changes to config files via shell. They get lost. You configure things via GUI. If it's not possible, modify the GUI code and submit a pull request against the current code… Not outdated one that noone can install. Useless.
2/ You do not produce any similar nonsense like binary patches mixing libraries from different binary packages. That has nothing to do with "work on the package". Noone will merge such crap.
3/ About 99% of the world abandoned junk like fax ages ago. Hardly surprising noone tests it.
4/ Before wasting time on trying to fix unfixable crap such as PBI, perhaps rather play with pfSense 2.3 and get it working there.P.S. My personal observation: There's tons of whole LOT more suitable places to run a PBX on. Such as some VM on a DMZed server. Frankly, why anyone thinks putting this monster on their firewall is a good idea goes beyond me. Especially when a VM-ready appliance incl. a configuration GUI is readily available for download! http://www.asterisk.org/downloads/asterisknow
-
@doktornotor - Maybe you don't know what the role of an SBC is. An SBC is not a PBX, although the package may be the same…
-
RTCP stats problem
CLI command 'sip show channelstats' issued during an active call: all data except duration is zero.
I've done 'rtcp set stats on'.
I've turned on rtcp debug: I get Sender Reports from both my endpoint and my provider's SIP proxy.Just wondering:
Where does Asterisk store the RTCP stats? Memory? Disk? If disk, does the Asterisk init script need to create another directory under /var?Thanks!
EDIT:
The problem is due to this Asterisk 1.8 open bug:https://issues.asterisk.org/jira/browse/ASTERISK-18455
I temporarily forced Asterisk to transcode and I started getting valid data from 'sip show channelstats'.
-
There might be a different cause. Please check the value of directmedia in sip.conf. The default setting is "yes", where Asterisk tries to redirect media directly between caller and callee. In this case Asterisk doesn't see any audio and hence cannot generate any statistics.
-
In sip.conf all of my device definitions include directmedia=no, so that's not it.
But thanks for the suggestion. -
The current Asterisk package generates an rc-file named asterisk.sh. This causes the service to get started two times in rc.start_packages, because the second instance cannot check that another instance is already running. It takes a moment before the pid file has been generated.
The package should generate a simple rc-file with the name asterisk, such that the manual boot time service does not get called.
-
The package should generate a simple rc-file with the name asterisk, such that the manual boot time service does not get called.
What second instance? The /usr/local/etc/rc.d/asterisk script is removed on install.
https://github.com/pfsense/pfsense-packages/blob/master/config/asterisk/asterisk.inc#L41
-
Nope, the file asterisk never gets generated, only asterisk.sh. And this causes the problem of two instances.
-
Nope, the file asterisk never gets generated, only asterisk.sh. And this causes the problem of two instances.
And it should NOT get generated. The only file that SHOULD exist is asterisk.sh. If you still have /usr/local/etc/rc.d/asterisk, just reinstall the package. (And, in general, do yourself a favor and do not upgrade packages on pfSense <2.3, uninstall and reinstall them instead. Otherwise, the updated install code simply is not used.)
-
I think currently only asterisk.sh gets installed. asterisk.sh causes problems. I have to setup a new box tomorrow and then I'll have a look at what happens at a fresh install.
<service>.sh should only be used for manual services outside any package. At least that's my understanding. Just have a look at rc.start_packages. Essentially $rcfiles = glob(RCFILEPREFIX . "*.sh"); grabs all .sh files and if a package uses the .sh extension itself; one potentially runs into problems if an executable cannot detect that another instance has already been started.</service>
-
Sigh.
1/ <service>.sh is used by pretty much any package out there. Usually generated by write_rcfile(). The scripts bundled with the PBI packages are NOT usable.
2/ As already noted 3 times, you should NOT have any /usr/local/etc/rc.d/asterisk script in there. If you have, then delete it or reinstall the package and it will delete is on install.</service> -
The asterisk script is not generated, only asterisk.sh, but this script is called two times during system startup. Since Asterisk cannot detect almost parallel invocations, two instances are typically running. That's a problem. Therfore I suggested to give the first invocation a chance to get fully booted.
If you don't believe me, insert a "logger" statement in asterisk.sh to see that "start" it is called twice at system startup.
-
FFS!!!! Your issue is having TWO scripts when you should have one, and that one should be called asterisk.sh. Reinstall the package or delete it manually. Explained 4 times by now. >:(
Period.
-
There's only asterisk.sh, and this script gets called twice.
-
Yeah, so get it fixed in pfSense core. Every damn package out there uses what I already explained.
-
Hoops! There was an "asterisk" script withoug the .sh extension…
-
Incredible. Won't explain for the fifth time. Pretty much every package out there uses <something>.sh with no problem. If you have issue with something called twice, then fix the code that's calling something twice.
And - while here… that pfSense core code show grow itself some brain and produce an API for disabling packages. Instead of people hacking code that creates the script on enabling the package and remove it on disabling. rc.conf.local ain't usable for this, perhaps/etc/rc.conf.d/ could.</something>
-
I just started a fresh 2.2.5 install (virtual machine) and the default installation starts Asterisk twice as described here:
https://forum.pfsense.org/index.php?topic=102591.0
asterisk.sh gets called twice and there are no old installations and there is no single asterisk script in the rc.d dir. A couple of days ago I added a logger() statement in asterisk.sh and the script was indeed called twice, which explains the two instances.Tomorrow I'll setup a new machine and then I'll report again. I have about half a dozen 2.2.4 boxes with older installations, so I cannot exclude that there are still asterisk scripts or whatever, like the one I checked about an hour ago.
-
Initially asterisk.sh gets called in the background and the .sh loop calls it directly, so a short sleep may or may not solve the problem.
I am too tired now, but my basic idea is that anything that gets called in the background with start_service(), will not get called subsequently. Should be easy to implement.
-
I am too tired now, but my basic idea is that anything that gets called in the background with start_service(), will not get called subsequently. Should be easy to implement.
Kindly post the output of the following (paste to Diagnostics - Command Prompt - PHP execute)
require_once("/etc/inc/pkg-utils.inc"); $rcfiles = glob(RCFILEPREFIX . "*.sh"); if (!$rcfiles) $rcfiles = array(); else { $rcfiles = array_flip($rcfiles); if (!$rcfiles) $rcfiles = array(); } if (is_array($config['installedpackages']['package'])) { foreach($config['installedpackages']['package'] as $pkgid => $package) { $internal_name = get_pkg_internal_name($package); unset($rcfiles[RCFILEPREFIX . strtolower($internal_name) . ".sh"]); } } var_dump($rcfiles);
since whatever you are describing simply doesn't happen with sane configuration. The .sh script just won't run from the $shell = @popen("/bin/sh", "w"); part because it's unset with the
unset($rcfiles[RCFILEPREFIX . strtolower($internal_name) . ".sh"]);
line.