it is a good news for asterisk and freepbx. Do you mind leave your email, I want to create a new space for freepbx in chinese.
Please use the email address near the bottom of the letter to reach me.
I encourage you to read the give serious consideration to what I wrote here, including my initial post and my follow up posts further down the thread…
FreePBX design discussion
13 posts were split to a new topic: FreePBX design discussion
In late January , we’re releasing updates for FreePBX to support the new, upcoming requirements for emergency calling.
I assume you mean “the new, upcoming American requirements” here. I trust this won’t get in the way for the rest of us? Any details on what changes this will involve?
In February , we’re doing work to improve pieces of infrastructure used by our open source projects.
LOL considering the module servers have been down for at least 24 hours, you may want to bump that one up a few weeks.
In the March/April timeframe, I’ll update you on the significant engineering time we’re investing to modernize some of the internal “plumbing” of FreePBX, to help it keep up with recent technology changes.
Dear god, please don’t tell us you’re moving more code away from PHP to NodeJS. Your short-sighted decision to require a whole new infrastructure for basic functionality means a lot of servers stuck at 13 over here. If you really wanted to move from PHP because of performance concerns, I would have much preferred to see some kind of compiled code like Python, Go, or Rust that didn’t require a whole new daemon.
more participation from me and from others at Sangoma in the forums
Just make sure it’s good participation. Ignore or respectfully engage with the trolls, and don’t immediately dismiss everyone’s problems as an error on their part. I haven’t been around the forums much, but these were definitely problems I saw in the past.
We are working on a series of short videos
I’d suggest making sure there are written versions of these, for the visually impaired (and people who just don’t like videos!)
Our aim is to make it easy to keep your system compliant with US laws, but not impede you if you’re not subject to US laws. I’ll be sharing more details later this month, but in general, the requirements of the new US laws center around being able to dial 911 directly (with no prefix), having administrators notified when someone dials emergency services, and making sure that outbound emergency calls have a valid e911-enabled DID.
I know that the mirror server has had issues again today, and I apologize for that. Let me just say that if it were as easy as just moving “that one up a few weeks”, I certainly would want that too. Please rest assured that it’s a priority for the FreePBX development team.
I haven’t seen much of those sorts of issues in the past few months, but I’ll certainly keep that in mind.
I’ll pass this suggestion on to the team that’s building the videos, thanks.
Telecom Industry Changes - Kari's Law / Ray Baum's Act / STIR/SHAKEN / TRACED Act
Hey @miken32 ,
Wanted to comment on this briefly. The reason nodejs was chosen way back in the day was because we needed a non-blocking daemon to service real time events for UCP (which was contained in the ucpnode module). At the time PHP was not performant in real-time non blocking performance areas (I dont think it really fits that well even today, you can’t make mysql or file operations in PHP that aren’t blocking and you can’t make non-blocking http requests nicely without a library like guzzle and guzzle only has async on php 5.6+).
Furthermore. When it comes to pm2 (which is a nodejs process manager). At the time there were no good PHP process managers that supported PHP 5.3 (there are some good ones for php 7.2+ though), there still aren’t because PHP 5.3 is dead. But that’s what FreePBX 13 supports so you end up stuck in a way.
Using nodejs in the first place was never a performance concern in regards to PHP. It was allowing daemons to be written in a language that is non-blocking. As I said before, PHP is a blocking language it was never written as non-blocking in mind (and still isnt even in 8). Though I don’t work on FreePBX anymore I doubt it would move entirely to NodeJS, that was never the goal and never even a thought. NodeJS was just for daemons that need to be non-blocking (Like Zulu, UCP and pm2 (which manages some php processes as well)).
NodeJS was also used in FreePBX 13 for many things. But we wanted to give our work back to the community. So we released pm2 in 13+ and released ucpnode inside of ucp in 14, that’s probably where some of your headaches come in and I’m sorry for that :(. Unforutnately there was no way to write a performant realtime UCP application without nodejs (yes it could have probably been done in python but you are back at the original problem, another language that isn’t FreePBX’s base… so does that really solve anything? Furthermore CentOS is still on some Python 2.x version, you can’t load in Python 3.x without causing all sorts of headaches (because CentOS 5-7 uses Python in yum) so the code, if written in Python would have to have been done in Python 2)). FreePBX needed a centralized process manager.
Additionally, as I talked about in a previous blog (Performance Improvements in FreePBX). There is another nodejs process in Core (which is extremely lightweight) that launches the older FreePBX AGIs through a FastAGI proxy (this is optional but gives FreePBX a huge performance boost). There’s a thread on twitter where I explained this at length for @mattf and someone from Issabel if you want to take a look.
Anyways hope that helps clear that up (and remember I’m just an outsider)
Finally. It’s worth noting that the Sangoma team in place now is highly skilled in NodeJS, they use and maintain one of their most active repositories on github which is the NodeJS ARI SDK.
And if you didn’t know one of @mattf’s previous roles at Sangoma was working on the product Respooke which was also written in NodeJS.
I don’t want this to sound like a round of excuses, just thought perhaps the context of why things were done the way they were done would be helpful and to let you know that this wasn’t a “short-sighted decision”. No project is ever going to get 100% of things right 100% of the time but it’s good for the community to know why things were done and at the time we (I?) should have been more transparent about why NodeJS was chosen.
Also wanted to give another shoutout to @miken32 who was (is?) the most active outside contributor in terms of code to FreePBX. You are one of the reasons that makes this community so great!
The AGI stuff was mostly what I was referring to w/r/t your implementing NodeJS for performance reasons. It’s not optional, as one can’t do the install without node, and with the majority of our PBXs being still on EL6, this was a challenging proposition to say the least! Trying to get it installed – and stable – was just too much of a hassle, with too many changes needed. (EL7 is no problem of course, so newer installs are running 15 without issue, and I’m running tests on EL8 now, with everything looking good.) It wasn’t the different language that was a problem, but the requirement for those additional daemons. I realize that most users are happy to let FreePBX control their entire system and just install the distro, so I know I’m a minority voice; I just like to grumble about these things every now and then!
Thanks, I don’t want to just grumble about things!
Yes, though a few providers offer notification, it’s far from universal and AFAIK not legally required at the provider level. Hell, Flowroute doesn’t mention notification in their current documentation, even though they are owned by Intrado!
A business is unlikely to switch trunking providers just for E911 notification. Using a different provider just for 911 is also problematic, because you aren’t regularly sending them traffic so you know the trunks are working.
Some providers offering 911 require that the DID be with them, i.e. you either must use them for origination or have the admin hassle of two DIDs per user.
If you have failover, e.g. in case of an internet outage you have one POTS line for 911. It may not send the proper address, but it’s a lot better than nothing. Especially in this case, notifying local security is important.
This is not a simple problem and doing notification in the PBX is IMO a cleaner solution.
Kari’s Law clearly states that the MLTS system, which in this case would be FreePBX, must do the notifications. This is not left to the provider/carrier. So saying “VoIP Innovations lets me send alerts for 911” makes VoIP Innovations MTLS system comply for you as their end user but the PBX you installed and connected to VoIP Innovations must do the notifications because next month they could move to another carrier/provider who doesn’t do those notifications and thus make them in violation of the law.
These laws are not just for carriers/provders these are for the makers and installers of the actual systems. In fact Mitel, a maker/installer of PBXes, had just as many input/comments on the law as Verizon and RingCentral (carrier/provider) had.
The FCC has recently published clarification regarding the notification requirement. You can read the full-text here:
Relevant to my discussion above, section 58 of the FCC’s statement makes clear that “the definition of MLTS refers to a system and that individual components of such a system, including telephone sets, control software and hardware, and adjunct systems, do not by themselves constitute an MLTS. Consistent with this, we clarify that manufacturers, importers, sellers, or lessors of individual MLTS components are not subject to the Commission’s MLTS rules to the extent that they manufacture, import, sell, or lease such components without the other components necessary for the system to function as an MLTS.”
If the FCC sticks with this position, then it would seem that FreePBX is not an MLTS and would have no need to do anything to comply with Kari’s law. Presumably, the person/company who aggregates the phones, the PBX, and an ITSP would be the “manufacturer” of the system and would have to ensure compliance. In the case of notification, compliance would mean configuring the feature if it exists.
I would expect that this will be a feature that will be implemented alongside the e911 settings for all ITSPs that serve U.S. customers very soon. Given that the notification must include the address and DID information, it would make sense to have the ITSP do it.
This. As someone who has, more than once, found and brought up bugs only to have them dismissed under a pile of stuff like ‘no one else has reported this’, ‘we need xyz log files’, ‘file a bug report’ and had posts and bug reports deleted, this is the single biggest issue I’ve had and continue to have with the platform.
While I’m not taking away or dismissing what you are saying let’s understand a few things here.
I actually have said this phrase more than I care to over my career. Because I am brought issues a single customer is having and someone treats it like it is the sign of the end of times. A single report of an issue either means that there really isn’t a wide spread issue or almost no one is impacted by it or not reporting it. In other words, it could be more of a support issue than a bug and the bug tracker is not for support issues.
Yet another phrase I have said a lot. These are important. Unless they have access to the system to look at all this, these hold vital information to help pin point the issue because another complaint from people has been the “works for me” reply. Understand that in order to solve the issue one must be able to replicate the issue or see the results of the issue. If neither can be done, then how would someone determine what is the cause of the issue and how to solve it?
Well for this one, I mean, if you have filed a report in the proper system then nothing is going to happen. The forum is for support not handling bug reporting/tracking/resolution. The devs do not work out of the forum they work out of the issue tracker.
So again, I’m not dismissing that a bug was filed and this closed out for X reason. It’s happened, I know. At the same time you have to understand people submit non-bug/issues to the tracker all the time, those need to be reviewed and determined if it really belongs there. Not to mention people tend to just report things with “calls stopped working, please tell why” or my favorite variations “it was working for X time and now it just doesn’t work, why?”.
I would say that while Sangoma could handle tickets better in the issue tracker we all have to admit that users have to put at least some effort in reporting their issues with details and information. Because some of this is on the users as much as Sangoma.
I will leave you will a phrase I say a lot as well, mainly when helping FreePBX users in IRC and even here on the forum. “Help me help you”.
I understand and as someone who does end-user support can relate. And it’s important to not knee-jerk react. Here, I strongly suspect that at least a few people have entirely stopped reporting issues because of the “it’s not us, it’s you” baseline response. So it’s important to be conscious and thoughtful about the responses. Along this line, locking threads after seven days is remarkably problematic. Many times issues I’ve posted or responded to have had “me, too” additions weeks or months later that were extremely helpful. Leaving the threads open keeps like issues together and insures that all who posted on the thread are notified. The latter doesn’t happen if someone has to start a new thread with a “I have the same issue as thread x” title…
An FAQ/wiki post for collecting the various kinds of log files would be helpful, if it doesn’t already exist. As someone working 12+ hour days I tend to get stopped when that request comes up and I don’t know how to collect the requested info.
It is linked all the time…
Bookmarked, thank you. FWIW, I’ve been here for many years and do not recall seeing that link attached to a “We need logs” request. It would be great to have on those posts as a default.
Probably gets shared once a day on average, maybe a bit less.