similar to: PJSIP Lockup

Thanks for the info, Joshua. Does PJSIP handle database access the same way Chan_sip did? We had a number of boxes running chan_sip referencing the same mysql server without issue. We're going to attempt to get a backtrace on the next occurance. We're also going to run a local copy of the database on the same physical asterisk instance and have the system reference it. Just to

On Mon, Mar 2, 2020 at 2:52 PM Nick Olsen <nick at floridavirtualsolutions.com> wrote: > Hello All, > I'm using Asterisk 16.8.0 on a Centos 7 box. Previously 16.5.0, But > recently upgraded to attempt to resolve this issue. Using bundled PJSIP. > The PBX is using mysql realtime for most functions. The Mysql server is on > the same lan as the asterisk box. > > As

We ultimately found this to be a voicemail issue. The voicemail is held in MYSQL as well (via ODBC). And we found when attempting to playback a customers voicemail unavail greeting is when the deadlock would occur (Immediately, every time. Throwing the same "task processors" errors, And making pjsip completely unresponsive). We had imported a number of greetings from a legacy asterisk

Paddy, It's pretty easy to spot from the CLI. A voicemail gets called. And the screen basically stops scrolling from there. Eventually you'll get the "Task processors exceeded 500 queued tasks" or something like that. And maybe channels attempting to hangup due to lack of RTP (If you have no-rtp timers configured). Once you find the problem mailbox, You can call it via any

Hello I am experiencing a freeze of the Asterisk proces when issuing a 'sip reload'. I have this issue every time on asterisk versions : 13.11.2, 13.11.1, 13.10.0 and certified-13.8-cert3. I do not have this on versions certified-13.8-cert2, certified-13.8-cert1 and asterisk 1.8.32.3. The only solution is a cold restart of Asterisk. I can execute any command on CLI except 'sip

Hello all, We would like to pull the RTT of registered endpoints from MySQL for use in a webportal. However it doesn't appear asterisk tables this by default like chan_sip did. I've found some information [1] that a modification of sorcery.conf can get it writing to a table. But I'm struggling to figure out what that configuration is. It seems the object is called

Thanks Joshua, I assume by query asterisk you mean I'll need to query it via AMI? Is that information available via AMI? *Nick Olsen* Network Engineer Office: 321-408-5000 x103 Mobile: 321-794-0763 On Tue, May 26, 2020 at 2:57 PM Joshua C. Colp <jcolp at sangoma.com> wrote: > On Tue, May 26, 2020 at 10:48 AM Nick Olsen < > nick at floridavirtualsolutions.com> wrote: >

Hi All This sounds just like a problem I have had and still investigating having moved to 16.9 using chan_sip. I am still trying to repeat the problem it looks from debug that the issue is either voicemail of call transfer but I cant consistently repeat it. Voicemail is using ODBC and I just imported the data from the old system into the new database. Nick - if you have any more info I

Asterisk 11.11.0 on CentOS 6.5, installed from RPMs. OpenSIPS fronting Asterisk from a Tekelec T9000. I'm accumulating stuck channels. I'm googling now and I recognize that Friday afternoons are the worst time to ask questions, but I'm getting desperate because this is keeping me from rolling a system out to production. (Yup, I know. Who rolls out a system on a Friday

On Fri, Feb 17, 2017 at 5:17 AM, Olivier <oza.4h07 at gmail.com> wrote: > Hi George, > > How does ast_coredumper compare to ast_grab_core ) ? > Is it worth learning to use both or shall favor one ? > > PS: As I don't know either program, yet, my question may seem silly. > Please, forgive me for this > Not silly at all. ast_grab_core actually kills asterisk to

On Mon, Jun 29, 2020 at 6:46 AM Joshua C. Colp <jcolp at sangoma.com> wrote: > On Sun, Jun 28, 2020 at 2:26 PM Dovid Bender <dovid at telecurve.com> wrote: > >> Hi, >> >> We have a box up and we are starting to see a lot of "Exceptionally long >> queue length queuing" in the logs. From all the research so far it seems >> like this leads to

On Mon, Mar 2, 2020 at 4:24 PM Nick Olsen <nick at floridavirtualsolutions.com> wrote: > Thanks for the info, Joshua. > > Does PJSIP handle database access the same way Chan_sip did? We had a > number of boxes running chan_sip referencing the same mysql server without > issue. > > We're going to attempt to get a backtrace on the next occurance. We're > also

Hello, I'd like to know if anyone of you is finding my same problems using any recent asterisk version, after 13.7 / 13.8 with chan_sip. If I use any recent asterisk version, after just few seconds asterisk completely locks up, stopping processing SIP/UDP packets. Nothing is written in the asterisk log, but if I run "netstat -nap | grep 5060" I see the UDP buffer filled up. If I

Hello list, I've got a whole lot of these in my debug log : [Apr 18 15:12:44] DEBUG[26973] audiohook.c: Read factory 0x1cea33a0 and write factory 0x1cea3dd8 both fail to provide 160 samples [Apr 18 15:12:44] DEBUG[26973] audiohook.c: Failed to get 160 samples from read factory 0x1cea33a0 [Apr 18 15:12:44] DEBUG[26973] audiohook.c: Read factory 0x1cea33a0 and write factory 0x1cea3dd8 both

Hello, Using asterisk 1.8.24 on CentOS 6.4 I notice that the asterisk process is using between 105 en 110 % CPU : PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1765 root 20 0 2508m 102m 8864 S 105.8 2.7 102:11.55 asterisk 2682 mysql 20 0 627m 29m 6204 S 0.7 0.8 1:59.51 mysqld 1 root 20 0 19228 1508 1220 S 0.0 0.0 0:00.75 init

Hello Asterisk list, I've facing a memory allocation issue that happens occasionally but on a consistent basis. The problem happens as follow, suddenly Asterisk starts consuming a lot of memory, in a rate of more than 1GB per hour. Kernel will eventually kill it via the OOM killer when memory is really exausted... This situation does not generate backtrace because Asterisk is responsive

Hi, We have a box up and we are starting to see a lot of "Exceptionally long queue length queuing" in the logs. From all the research so far it seems like this leads to their systems crashing and being unreachable. In our case the box remains up and takes calls. We are running Asterisk 16.6.1. We are using MusicOnHold to play online music streams via ffmpeg. Any idea on how to

Hello, I'm load testing a new Asterisk 13 system (Debian Stretch, packaged asterisk). One system writes CDR though an ODBC connection to a local Postgres database over the LAN. When sending 50 new calls per second with SIPp, I'm seeing one system outputs : taskprocessor.c: The 'subm:cdr_engine-00000003' task processor queue reached 5000 scheduled tasks again. This [1] thread

Hi, While compiling 1.8.8.1, I met the following error: [AR] hash/hash.o hash/hash_bigkey.o hash/hash_buf.o hash/hash_func.o hash/hash_log2.o hash/hash_page.o hash/ndbm.o btree/bt_close.o btree/bt_conv.o btree/bt_debug.o btree/bt_delete.o btree/bt_get.o btree/bt_open.o btree/bt_overflow.o btree/bt_page.o btree/bt_put.o btree/bt_search.o btree/bt_seq.o btree/bt_split.o btree/bt_utils.o db/db.o

On Wed, Aug 9, 2023 at 3:20 PM Dan Cropp <dcropp at amtelco.com> wrote: > I have a customer who just encountered a crash while running Asterisk > 18.17.1 version. > > > > I’m trying to adapt to the changes so not sure where best to look or how > to possibly report this. > > > > I started by going through >