You might be into semantic pissing contests. I am not. Buzz off will ya.
I am absolutely with @PitzKey on this.
You said “doesn’t appear to do anything”.
He was trying to show that it does work. It also works for me. It could be better but it does work.
Please explain exactly what does not work!
Actually what it does is a full Asterisk Dump among other things.
If you can not even really explain what is NOT working, how should we be able to help?
So would you please mind to do so?
When you say “Call Diversions” what do you mean exactly?
I change the FollowMe and CFI in the Database myself. Then do “Apply” API and everything works as it should.
As a sidenote: you are one of the most annoying and unfair people i have ever met. And i have not really met you, luckily
Maybe that’s why not even the support wants to help you and don’t care about your money?
Guys, as a mod, it is my duty to ensure this forum is and always stays a welcoming and friendly forum.
It is unfortunate that OP found my input as an attack, it was absolutely not intended to be one.
So, please remember to act respectful to each other, and please refrain from calling other people (including the VitalPBX staff) names or characters.
Not pointing fingers: But if you think that your post contains comments that can be said in a more positive way, please edit it and do so.
Okay, this was actually useful to me. It got me thinking differently. The other stuff is nonsense. You guys want a buddy then go onto the facebook or something.
It appears that the most recent 3.1.1-1 did address the issue. Maybe even the update prior to that? VitalPBX addressed it by now simply doing a full config dump and reload, unlike before. That’s not exactly what I’m looking for, as we’ve been doing that anyways via the AMI. It also disrupts call audio while it does that. That is NOT what the VitalPBX GUI does when you, for example, click the DND tick for an extension. It is fast and non-disruptive. That action is doing something other than apply_changes, and that is what I’ve been looking for. That has been mentioned to support in the myriad of tickets (in different ticket systems no less) on the subject.
By the way, our “error” was in the timer for the curl call. Since VitalPBX changed it to do a full system reload, yeah, it now needed more time. Again, this should not be needed for a simple call diversion adjustment.
The “fix” in all of this is a series of API calls that do exactly what the diversions do in VitalPBX’s GUI.
This is how you came out of the gate, exclamation point and all. You want to enlighten me on how I’m to take that?
Even though mo10 did talk in passive agressive circles, he did offer some semblance of empathy and technical enlightenment. For that I am grateful.
REGARDLESS. This solution is still not in place and acceptible for any production environment. You can even argue that now the apply_changes call does not work as advertised in that while it requires a tenant ID, that doesn’t appear to matter anymore as it blows up the entire system, all tenants, thus the long delay and loss of audio during the interim.
We need non-call-disruptive API calls for Call Diversions and Voicemail PIN edits. Please. Pretty pretty please with cherries and whip cream on top for those who’s feelings got hurt.
“Apply Changes” API was not changed afaik.
And don’t worry: calls don’t get dropped. It’s not restarting asterisk.
Just test it while making a call.
As said: it’s not perfect but it works.
You can test again and offer changes needed.
I see what you are asking for but can not do much if not even the support wants to help you.
I have no idea what suggestions you made on tickets and how you talked to them.
Seems like you need to know what exactly is done in extension status on changing things.
Do the voicemail pins get saved on apply Changes API?
No, we’re seeing call audio “pause” for about 5 seconds. That’s just enough time for many folks to go through the “are you there? can you hear me now” process, hangup, cuss and call back.
This might be because the firewall gets reloaded as well?
Ping your server while you do Apply Changes API.
Yes it is the restarting of the firewall dropping the audio. Good find. Not like we can do anything about it though unless VitalPBX adds some flags or attributes to the apply_changes API call to ignore the firewall.
Folks let me reiterate that this is how debugging works. Someone, or many someones, report a problem. We put our collective heads together to find the solution. That was my “bullhorn”, squeeky wheel gets the grease reasoning for creating this post. I literally sat idly for months and months with next to zero participation from VitalPBX. Classic case of ignoring and ultimately shooting the messenger.
I’m not going to be VitalPBX’s messenger any more and get shot at every goddam time I report something. I’ve got other more pressing things to do such as run my businesses. If it fits it fits, if not so be it. We’ll work around it. Adios amigos!
The method to apply changes through the API doesn’t set up the firewall rules. The delay while dumping changes or the voice breakdown could be related to the system usage and hardware capacity. As it has been said multiple times, Asterisk is a multi-thread application which means that it doesn’t matter the number of cores in your PBX.
The cores and RAM can indeed be used for other processes or applications, but it is essential to know that Asterisk doesn’t take advantage of them. So if your PBX is being used for multiple customers or has high traffic, it is expected to lost audio or breaks communication while applying changes because Asterisk might get overload.
As being said by @mo10, the API dump all the settings of a tenant. This process includes the generation of the SQLite data on Asterisk that might be heavy depending on the amount of data to be created.
There’s an option in the PJSIP Settings that is supposed to help with audio disconnection; this option is “Allow Transports Reload” and has to be disabled after configuration the NAT settings.
See, why couldn’t you just answer like this a year ago? 6 months ago? 3 months ago? Yesterday? Making me traverse down every rabbit hole imaginable. So instead I had to go get a bullhorn and rant in a public forum. From Pitz’s exclamation points to mo’s “I don’t really know you but you suck” to your own “take your business elsewhere” I finally, FINALLY, get an explanation from the person that would know.
I don’t which to go with… Thanks! or Thanks?
By the way, I tested the firewall per mo10. Ran apply_changes that took about 30 seconds. 25 or so calls going on. 20% or so resources in use. Lost audio. Could literally see people hanging up and calling back in. I could almost hear them cussing at me. Turned the firewall off. Ran apply_changes again which only took about 5 seconds. No loss of audio. Did this routine three times to make certain. That’s why the firewall explanation made perfect sense. Throwing resources at it is only a few clicks and dollars. I will do that.
I’ve now thrown up to 8 cores and 32 gig at this thing and still getting audio dropping for 5 seconds or so with 50% CPU getting gobbled up and the whole process taking about 15 seconds. With the firewall off, no audio drops, only about 10% CPU consumption and the whole process taking only about 5 seconds.
If I go into the VitalPBX GUI to Firewall Settings and merely click Save, audio drops for about 5 seconds and the process takes about 10 seconds to complete.
Clearly apply_changes is doing something with the firewall.
I’ve tried changing several ports directly in the database, and after applying changes, the ports modifications were not applied to the IP tables. I’ve checked the source code several times, and there’s no chance that the firewall got reload when using the API.
Remember to consider the CPU speed. With large installations, something like 3 GHz to 4 GHz sounds adequate.
@intelesync, I’ll say it again. My intention was to help and provide assistance.
Please STOP making fun of people, calling people names or characters.
Not everyone speaks or writes English very well, and can sometimes be a little hard to come across. In fact, English is my third language…
Please read our responses with no feelings attached… We’re here to help you… Look at our records on this forum and in the old one.
When I tested the API, calls did not drop audio. I’d like to reproduce this - is there anyway you can provide us with the exact information you are doing?
Also, please provide us what/which changes you made and didn’t get applied when you reloaded
@miguel thank you for your input.
There is clearly something happening that will not even allow ping (icmp) to go through. Up to some seconds of downtime. I have addressed this before as well since this can be a big issue on many installations out there.
You could do a remote session if you want to see what is happening there since this will not effect new small installations much but as soon as you have some extensions, routes and so on the downtime will extend. Even if you have the best hardware in the world.
There is clearly something different happening then like in the Web-Gui apply changes.
Maybe if we can not find a solution for the “apply ALL changes” we could have a way to apply certain modules through the API?
Please help accordingly. Thanks.
EDIT, here we go:
firewalld is involved somehow on the “apply changes” API. This will cause the dropouts.
dump_asterisk_c is only at 10% CPU. firewalld at 11%.
After everything is done firewalld is not even found anywhere in TOP. So consuming almost none CPU anymore. Hope this helps finding this.
507 root 20 0 408728 71304 4224 S 11,0 7,0 2:54.73 firewalld 25483 root 20 0 364004 42892 12404 S 10,3 4,2 0:01.31 dump_asterisk_c
When Firewall is disabled, this problem does not happen.
“Jerry, this person hates me so much, I’m starting to like’m.”
@intelesync please stop offending community members and the VitalPBX team. This is a forum for mutual collaboration between the community. We invite you to remove all sarcastic and offensive comments from your post.
The policies of this forum prohibit offensive expressions both to any member of the community and to the VitalPBX team.
We have tried to solve all your requests in the helpdesk. However, it is our policy not to respond to tikeck that contain offensive words.
We invite you to continue using our support platforms in a friendly and clear way.
Hold up now. Exactly what was offensive where I didn’t simply punch back at someone either telling me I’m crazy, technicians responding with the classic “it works for me”, etc? I’m not just going to sit idly by while I get the living hell beat out of me for simply wanting:
A: The problem acknowledged that has been reported for over a year.
B: A fix.
Again, kill the daggum messenger. Gheesh guys. I mean, just gheesh.
The thread has been closed for mis-conduct. You can follow a new thread with regards to the ‘Apply_Changes firewall’ subject here, API apply_changes problem.