similar to: Asterisk crash on core show channel

Thanks for you answer Marcus, So maybe this means some bug was fixed? Anyone aware of something related? >From the release notes, I couldn't find any direct change that could fix this.... Thanks, Kind regards, Patrick Wakano On 21 February 2018 at 20:29, Marcus Kvarsell <Marcus.Kvarsell at fogwise.se> wrote: > Hello, i found upgrading to asterisk 15 helped. > > > >

I don't know AGIspeedy, but I have some PHP scripts where I set a connect timeout using streams. Example using https, but should be easily adaptable to non-s http.: $pbxsh_bin = @file_get_contents("https://blah.blah.blah", FALSE, @stream_context_create(array('https' => array('timeout' => 5, "verify_peer"=>false,

Hello list, Hope you all doing well! Recently, I had an issue with a FastAGI PHP script, which under some specific situation would run into an infinity loop, consuming all CPU resources. This also was preventing Asterisk to terminated the call properly because it was waiting for the AGI to return... The application uses AGIspeedy to process the AGI calls, not sure if this can be affecting this

Please can i ask you i want to know which code can help me to provide the taxation of voip/toip services in asterisk Le mar. 18 sept. 2018 à 01:36, Patrick Wakano <pwakano at gmail.com> a écrit : > Thanks everyone for the answers! > I did explored some options at the PHP level and probably will do > something in this direction, but in fact what I was really looking was >

Hello list, Hope all doing well! I've been checking some cases when a Dial fails and dialplan execution continues to handle this. I am finding it a little confusing how we should handle the DIALSTATUS and the HANGUPCAUSE in this situation.... More specifically, I am facing a case in version 13.6.0 where I am getting a DIALSTATUS=BUSY and HANGUPCAUSE=19 after receiving a 480 SIP error. Seems

Hello Asterisk list, Hope you are all doing well! We are using the MixMonitor application to record the calls and under some situations the call can be spied using ChanSpy with whisper enabled. Sometimes the spying channel is a person who can interact in the call, and some other times it is a sound file playing a message. The problem is that for some reason the MixMonitor does not record whatever

Hello list, Hope you all doing fine! I've tried to use the 'alias' directive in the indications.conf file but apparently it doesn't work.... It looks like maybe this feature was removed, because old sample for the indications.conf file have example using the alias parameter, but newer samples don't have it anymore.... also I couldn't find any ticket saying this parameter

Thanks Dovid! Indeed looks a bug but regardless of this, this problem made me think that the HANGUPCAUSE could be used for this purpose with benefits. I couldn't find an explanation about when DIALSTATUS would actually be better. The HANGUPCAUSE was reworked in version 11 ( https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause) but I didn't find someone actually stating it is a better

Hello list, Hope you are all doing fine! I have stumbled over some piece of dialplan code in which apparently they were trying to avoid recording the DTMF tones in the wav file. It is really messy and I am not sure if this really works. So after a bit of research I found this comment ( https://community.asterisk.org/t/asterisk-dtmf-record/65040) in which it is said: *"Asterisk strips the

Thanks very much for the reply Joshua! So I guess that setting dtmfmode=auto would be the safest choice in order to strip out the DTMFs from the recording, right? Cheers! Patrick Wakano On Tue, 1 May 2018, 19:36 Joshua Colp, <jcolp at digium.com> wrote: > On Mon, Apr 30, 2018, at 11:23 PM, Patrick Wakano wrote: > > Hello list, > > Hope you are all doing fine! > > >

Hi Kevin! Thanks very much for your reply! Much appreciated! So I just have a remaining question from this, if the with-ssl is not mandatory to have the encryption support, what is it actually used for? Maybe it is some old flag which is not needed anymore and so can be ignored for now and possibly removed from the configure/makefile stuff for future releases? Kind regards, Patrick Wakano On

Hello list, Hope you are all doing well! I am facing a problem when compiling Asterisk 16.8.0 in a CentOS 6 box and I wonder if someone can put some light on it. Log history short, install_prereq fails to install the packages (not sure how important they actually are....): speexdsp-devel, gmime-devel, uriparser-devel, iksemel-devel, uw-imap-devel, hoard Then, I am running the following commands

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

Hello George, Hope this finds you well! I wonder if there has been any progress on this matter? I've been working to have Asterisk running on CentOS 8 and our jump from CentOS 6 to 8 doesn't look too bad.... The missing packages found are: gmime-devel, iksemel-devel, corosynclib-devel, libresample-devel, hoard and python-devel. Python-devel could be replaced by python2-devel or

Hello Asterisk Users, Hope you all doing fine! I am working with a quite complex dialplan, and I've come to some situations where it makes some nasty use of pre-bridge handlers. The pre-bridge handlers wiki (https://wiki.asterisk.org/ wiki/display/AST/Pre-Bridge+Handlers) doesn't have the big warning the pre-dial one has indicating it must return and must not put the caller/callee in

Hi, I'm maintaining the FreeBSD ports for asterisk(With madpilot at FreeBSD.org as identity). Here's a link to the asterisk13 port for your reference: http://www.freshports.org/net/asterisk13/ I performed some tests with RC1 and am doing some final tests with the final release before committing the update. Up to now the ports forced using gcc, version 4.8 lately, to compile it. And for

After an upgrade to Asterisk 12, I'm "collecting" channels. When I enter and then exit a conference room, I see: -- <CBAnn/207-0000067f;1> Playing 'confbridge-leave.slin' (language 'en') -- Channel CBAnn/207-0000067f;2 joined 'softmix' base-bridge <5edb1920-3774-4ba3-8c4d-23e8fd04519c> -- Channel CBAnn/207-0000067f;2 left

At the current time, we do not recommend attempting to build Asterisk on CentOS 8. Many packages Asterisk uses are not yet available and would require building from their sources. The Asterisk packages are also not available in the EPEL 8 or CentOS 8 repositories yet for the same reason. We'll update you when we think it's safe. -- *George Joseph* Digium - A Sangoma Company |

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 https://github.com/asterisk/asterisk/compare/18.17.1...18.19.0 to see if any of the changes seemed to apply to code reported by the backtrace. Entirely possible I missed something,

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