well that should map incoming packets to 5091 to 5060, but may not rewrite
[new] outbound packets from 5060 to 5091, which your isp may be blocking.
an iptables SNAT or MASQUERADE might help you there. i'm not positive on
if this would be needed or not.
more importantly, however, if your is
has anyone tried out using taskset/isolcpus/cpusets in any way with
asterisk on linux? any feedback if so?
as far as i can tell, aside from mpg123 and agi calls, asterisk doesn't
appear to be threaded or fork in any way, so if i've got a multiproc
system whose primary responsibility is aste
i've encountered similar problems with the last line of an:
asterisk -rx "iax2 show channels"
with 1.2.7.1, i can typically expect the last line, which is "n active IAX
channels" to appear. with 1.2.9.1 it's a complete gamble, typically not
displaying (but fine if run from interactive console
yeah this post is old and there have been dozens of replies, but here's
some feedback for the list, now that i have some.
we're using a sangoma a102 card (no hw ec) with 2 pris from sbc.
asterisk 1.2.7.1, zaptel 1.2.6 (much testing previously with 1.2.5). we
first used:
KB1 (not aggressiv
Try shutting off asterisk/zaptel and unloading any zaptel modules
(rmmod zaptel, wcfxo, etc) before doing the make install, so udev removes
any /dev/ entries associated with them (ie /dev/zap/transcode). If not
using udev/devfs, then perhaps unload all zaptel modules, rm -fr /dev/zap,
then m
this problem seems to occur in 1.2.9.1 (1.2.9 also? dunno about 1.2.8)
with users of chan_agent and agents making transfers. Kevin P. Fleming
<[EMAIL PROTECTED]> was looking at the issue last i read on this list.
check out the thread "1.2.9.1 crashed today" on this list over the last
~1.5 w
On Thu, 22 Jun 2006, BJ Weschke wrote:
On 6/22/06, Matt <[EMAIL PROTECTED]> wrote:
We're now back on 1.2.6 and running stable. Been running for over 17
hours. Something is wrong with 1.2.9.1
Sorry. I may have asked this already, but are you running the tarball
releases or checkouts from
we're also seeing a similar problem with 1.2.9.1 (previously 1.2.7.1,
without this error). our manager interface is used a fair amount from
FOP, and reloads occur staggered throughout the day on changes (but not
super often).
when the problem occurs, we see a lot of agent and queue function
You may need an:
allow=gsm
for the appropriate channel config, ie sip.conf, or iax.conf.
-tcl.
On Mon, 16 Jan 2006, Ken D'Ambrosio wrote:
Hi, all. My president wants to have a custom greeting for our bridge.
So, I had it recorded (as foo.gsm), modified app_meetme.c to reflect the
new filen