Suggestions for future versions of FreePBX

FreePBX Development
1

[This post and many that follow split from unrelated thread - mod]

Since we’re talking about the direction of FreePBX, I’d like to take this opportunity to urge you to:

  1. Simplify the UI and make it lighter and faster. Get rid of fancy graphics, floating submit buttons, hovering tooltips, obfuscating password fields, sticky menus, tabs, tables that only show me 10 entries unless I select 25, or 50, etc. The UI is something that none of my users ever see. I see it, but I don’t need it to be pretty. I want it to be efficient and fast. I want it to open on any browser - even one 10 years from now that doesn’t support the fancy new features of today that will be deprecated by then. A simple text based interface with basic HTML elements that will load fast and work forever is all that I need.

If you really feel that you need to do more than that, then bake the documentation right into the module, instead of requiring me to find a wiki page that is, more often than not, broken or incomplete.

  1. Give me the option during Distro install of not including commercial modules. Everytime that I’ve tried to uninstall all of them after a distro install, I ended up with an unrecoverable error. I know that you want me to buy the commercial modules, but shouldn’t it be my choice whether they get installed in the first place?

  2. Rather than disabling chan_sip and forcing everyone over to pjsip, why not give a short blurb explaining the difference between the two and then ask during the install which should be installed. This really won’t affect me, but just from browsing the forums, I can see that large percentage of the forum posts are now about pjsip problems. As someone else already noted, by switching to pjsip, you’re breaking about 80% of the trunk-related documentation that is available in various spots on the internet.

Re-enabling chan_sip is just going to be added to my list of things to do, right after I disable responsive firewall and configure iptables in a way that I know is secure.

  1. For the pjsip module, please add free form field that allows the user to add additional pjsip options. The last time I checked, there were pjsip options that I’d like to use (such as the one for qualify frequency) that were simply not present in the FreePBX GUI. For chan_sip, I could just add them in the PEER details. There should be a similar option for pjsip.

  2. Consider making the System Admin module an open source module, as it was when it was first introduced. Making a commercial module surely increases registrations, but it also means that it cannot run on open source installations. If you really don’t want to do that, then at least document how to make the FreePBX (non-OS) entries that it allows a user to configure manually.

2 Likes
5
  • Chan_SIP is an officially deprecated module/driver.
  • It has been under community support since 2014.
  • New features/updates/modifications to Chan_SIP are no longer being accepted by the Asterisk Project.
  • As of Asterisk v17, you have to actively enable Chan_SIP during configuration/make time. It no longer auto compiles.
  • Chan_SIP will be removed from Asterisk as of v21 (2023). It was slated for v19 (2021) but was pushed back to give the FreePBX project more time for migration.

Asterisk and/or FreePBX disabling/removing Chan_SIP does not break 80% of the trunk-related documentation on that is available all over the Internet. It makes it no longer applicable, on top of that most of these places will be ITSPs or other providers providing configs to their users for Chan_SIP. If they do not have Chan_PJSIP versions of these configs then it is clear the ITSP/provider is not paying attention to the project and doesn’t care.

Asterisk v12 (12/20/2013) is when Chan_PJSIP was introduced. By Asterisk v13 (10/24/204) it was declared Chan_SIP would no longer be receiving development from Asterisk directly. All development of future SIP features would be done within Chan_PJSIP.

When Chan_SIP is removed it will have been 10 years after the introduction of its replacement. A decade is more than a graceful period of time for anyone or any project to get with the program. Anyone who hasn’t, even by now, has either been dragging their feet or completely ignoring what happens with the Asterisk project in general.

And the mere fact that Chan_SIP and app_macro have been pushed back from removal in v19 to v21 due to FreePBX means that the FreePBX project has woefully been dragging its feet.

4 Likes
6

Tom,

Thank you for responding. I appreciate your well reasoned and detailed response to my suggestion about enabling chan_sip.

I already knew all of the things you listed, and I think that many of them support my position. Chan_sip is stable and mature. It is no longer being developed because, basically, it works.

I know that some people have a preference for newer things. If you watched “How I Met Your Mother,” you’ll see that the Barney character (played by Neil Patrick Harris) claims that he has only one rule: “Newer is better.” In other episodes, he declares equally confidently that he has only one rule: “Older is better.”

In this case, there are good arguments for both positions. Here, I’m not arguing that FreePBX should get rid of pjsip. To the contrary, I’m quite happy that FreePBX is providing support for pjsip. I even offered suggestions on how to make the pjsip module better! However, right now, I believe that FreePBX should continue to have chan_sip enabled by default. Eventually, pjsip will be as mature, stable, and reliable as chan_sip. It’s not there yet. It will be eventually. Conversely, the fact that chan_sip is old (mature) and not supported (finished) doesn’t mean that it is time to put it out to pasture.

I think your point above is a semantic one. People who try to configure FreePBX often have to resort to sources all over the internet. 80% is probably a low number. The vast majority of the documentation out there is written for chan_sip.

Yes, I’ve warned several times that FreePBX is pushing itself towards that very outcome. Many of the ITSPs no longer care about FreePBX or Asterisk. And it’s not just the ITSPs. WiseOldOwl and MichiganTelephone are both long gone. One of the devs from Australia (Mik?) is gone. Ward Mundy, who used to one of the project’s most vocal third party supporters, has vacillated from open hostility to what I can only describe as nuanced support.

There are lots of reasons why this has happened. A lot of it has to do with the open hostility that the community directs to anyone who dares to criticize the project. I’ve already seem one response to my post that was basically just a personal attack, and I’m sure that a few more will show up in the next few days.

Another reason is the multitude of other choices that are available, 3CX, softphones, ITSPs that offer PBX features, FreeSwitch, etc. are all competitors to FreePBX. The harder it becomes for new users to configure FreePBX, the more likely that new users are to make other choices. These problems don’t affect me: I know how to use FreePBX. But, I want it to be around in another decade, and in the world we live in, there’s no guarantee of that. The best way to make sure the project survives is to make the project as accessible as possible to new users.

And when chan_sip is removed from Asterisk, I won’t have any problem with FreePBX not supporting it any longer.

It seems clear to me that Asterisk will continue to support chan_sip until the devs decide that pjsip is as reliable and bug free. Until then, chan_sip is the reliable choice.

Anyway, thank you again for your reasoned and well-written response. I hope that we can continue a civil discussion on these points.

7

It’s no longer being developed because it hit a ceiling and to bring it to be more inline with SIP standards it would have require a complete rebuild. In the grand scheme of SIP stacks/drivers, Chan_SIP was lacking in some basic features.

PJSIP, the core of Chan_PJSIP, has been around since 2005. It has been used in quite a few projects including being the SIP stack of MicroSIP. Asterisk 1.2 was released around 2005. So when Asterisk decided to port PJSIP into the project it was just as old and mature as Chan_SIP was at the time. It’s also been in Asterisk for almost 8 years now, Chan_SIP was also roughly 8 years old by the time Chan_PJSIP was introduced.

So in 2013, Chan_SIP no longer needed development because it was mature and stable at 8ish years old. 2021, Chan_PSJIP is 8ish years old with PJSIP being 16 years old. It is still not mature and stable. I find that point of view a bit skewed.

I think you failing to grasp that there is numerous websites out there with outdate documentation and configuration how-tos for various projects including OSes and other software. It is not the vendors responsibility to go around and tell ever website to update their stuff, people who use the project or are supporting users using the project should be keeping themselves updated.

I’m not sure how it is clear they are supporting chan_sip. No Asterisk developer touches it really. Chan_SIP issues are left to a community member to deal with. In fact, chan_sip updates submitted by community members are one of the biggest sources of regression in current versions that the developers have to then deal with. They are rejecting any new submissions to chan_sip. There is no support from the Asterisk project on chan_sip.

As for Chan_PJSIP, I’ve been running it for years now. It performs better, gives me more flexibility and has been just as reliable and bug free as Chan_SIP was 8 years into its life.

8

Thanks again for taking the time to respond.

Sure, that too. But, the fact remains that chan_sip wasn’t abandoned in the middle of development. It is finished, and it works great. Sure, there are some things that it doesn’t do, but the vast majority of users don’t need them.

If it didn’t work, I’d be all for disabling it. But, it does work.

I think that you fail to grasp the extent to which FreePBX’s success is due to these websites. They’re only outdated because the devs make changes that make them outdated. People who voluntarily write up blog posts and documentation for the project don’t have any responsibilities to the project. The devs don’t have any obligation to correct these third party websites, but if the how-tos don’t work, people will look elsewhere.

A best practice when developing software is NOT to break the documentation, unless you absolutely have to. Software that radically departs from prior designs without a really good reason have typically ended up in the dustbin. Just ask Corel. WordPerfect was the defacto standard for word processing until they redesigned the whole program. At that point, instead of learning the new interface, the world just switched to Word.

Keeping chan_sip enabled means that these how-tos will still work. And informing users of the alternative and allowing them to use it will allow for a better transition. Eventually, pjsip how-tos will outnumber the chan_sip how-tos - and then it will be time to disable chan_sip default.

As you noted in your prior post, many of the ITSPs are basically ignoring FreePBX now. I warned of this in a post a few years back. I’m warning of it again.

Ten years ago, every major ITSP catered to FreePBX and Trixbox (a FreePBX port which was nearly identical to FreePBX). Nowadays, FreePBX and Asterisk support is an afterthought for many, with the notable exception of ClearlyIP, and their affinity for FreePBX comes from the fact that Tony headed FreePBX for several years and somehow managed to take most of the devs with him.

I apologize for my lack of clarity on this point. What I should have said was that Asterisk will continue to include chan_sip as an available option until the devs decide that pjsip is as reliable and bug free as chan_sip is. You are correct that they’re not “supporting” it, in the sense that they are not adding new features or improving it anymore.

The forums and the Asterisk bug tracker seem to indicate that pjsip still has some growing to do. My experience matches that, though I do use pjsip in some cases, it is not as reliable as chan_sip.

And again, thank you for your civil, polite, and well-thought out responses. I’m glad that we can agree to disagree on these issues without engaging in the mud-slinging that I’ve seen in the past.

9

It’s my impression that 90%+ of that documentation is wrong,even if it sort of works, so forcing people back to first principles is a good thing.

1 Like
10

Can you please explain why that after you’ve been told that Chan_SIP is going to be removed in 2 years, you insist the developers will continue to keep it around? The developers have already decided that PJSIP is reliable and bug as as chan_sip. They decided that years ago.

It does seem like you are exhibiting the exact thing I was saying other projects and places don’t do. Not paying attention to the project. People need to start using PJSIP for their stuff and they should start figuring it out now because they are already behind the curve.

https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Deprecations

11

There are still some edge cases that are not supported by chan_pjsip, e.g. setting the To header independently of the request URI.

12

Thanks for your suggestions @AdHominem. All are noted.

I will address the chan_sip vs. pjsip point specifically. This is the age old clash of tried-and-true vs new-and-improved. There are merits to both, and the project strives to strike the right balance. Now the old driver is EOL so the project is moving to the new. For 6 years, the FreePBX community has endured the confusion created by having multiple drivers listening on multiple ports. For 6+ years now, many in FreePBX and Asterisk communities have been testing pjsip, identifying missing or broken features and filing tickets. Others have put off the task of updating skills and knowledge. FreePBX will support chan_sip as long as it’s practical, but it is not a project goal to support it indefinitely.

Five years ago it may have been appropriate to advise users to use chan_sip in favor of pjsip, but no longer. Anyone who uses chan_sip today is starting out on day one with technical debt. Any posts that explicitly recommend using chan_sip without also including a disclaimer of the risk will be flagged as inappropriate.

1 Like
13

And this changes my statement how? Yes, there are edge cases but then again, people are trying to push new features in the chan_sip because of their edge cases. And really when you look at these edge cases there are reasons they are on the edge.

1 Like
14

This is something @jcolp has brought up repeatedly for 5 years. If there is some feature parody missing open a ticket. Is there a ticket open on what doesn’t work? As seen elsewhere in these posts people object to change. They will fight it to the point they become an annoyance.

At the end of the day this is a PBX and you don’t need to ever touch it except move/add/change

I have worked on Merlin systems that were in place for 30 years. Not long ago I saw a trixbox 2.6.2.3 still up and running happily. There is never a need to hold back progress for everyone else simply stay with what works for you.

4 Likes
15

I haven’t insisted that they keep it around. Rather, I have suggested the FreePBX devs to keep it enabled by default, or to have the installation process include an explanation of the two different options and ask the user whether he wants chan_sip enabled or not.

Also, my comments was in response to your comment noting that its life had already been extended once. You suggested that the reason its life was extended was some deficit on the FreePBX side. My response was that it is more likely that the devs saw that pjsip was not yet ready, and that is why chan_sip’s life was extended. Here’s what you said:

If I have understood a later post correctly, you were mistaken, and so I think none of this part of our discussion really matters - other than the fact that Asterisk still supports chan_sip, it still works just as well as it always has, and that removing it will create a barrier for new and existing users that will undoubtedly flood the forum with support questions.

Well, you’re mistaken. I post comments here because I like the project and want it to survive. Also, I can walk and chew gum at the same time. Similarly, I can use (or figure out) pjsip while still using chan_sip. I have both trunks running on my system right now. Where pjsip works, I use it. But, where it has problems, I don’t.

My concern remains with new users. A new user will see a great guide written somewhere, try to follow it, and give up when the Trunks module doesn’t look anything like the guide. Then, he’ll switch to FreeSwitch or 3CX. The project will die by a thousand cuts. I don’t want that to happen.

16

The chan_sip module was always scheduled for 21, to give ample time for people to move. It wasn’t due to FreePBX itself. It was decided originally when removal was proposed during an AstriDevCon if I recall and not because PJSIP wasn’t ready, but because chan_sip was such a substantial thing for so many people we wanted to give ample time.

2 Likes
17

Hi Lorne, and thanks for taking to the time to address some of my comments.

I don’t have any problem with any of what you had said. But, moving to the new doesn’t necessarily mean eliminating the old.

Well, that confusion is entirely of your own making. I’ve said it before, and I’ll say it again: You need better documentation.

That is all perfectly reasonable, but none is a reason disable chan_sip by default in new installations.

Any technical debt today is the same as the technical debt five years ago.

Well, that’s just silly. As long as chan_sip works, and it’s included in FreePBX and Asterisk, people should be allowed to recommend its use.

18

Alright, I may have lumped it in with the app_macro for FreePBX as the reason.

19

And that is the same reason that I believe that chan_sip should remain enabled by default in new builds of the FreePBX distro, or that, at least, the user should be given some kind of notice during the installation of FreePBX so that they can make an informed choice.

I recognize that the new user will be able to enable it in the advanced settings module. And you guys will be fielding a ton of such inquiries here in the forums and giving that very same recommendation. :slight_smile:

20

What is being referred to in the amount of deployments with chan_sip still in use. A new user that has never installed FreePBX should not be starting with chan_sip so they can be told to move away from it within the next 2 years. When the goal is to get existing users to migrate the best plan is to not keep adding new users to that list. You stop new deployments from using the thing you’re trying to remove and work on getting the existing people to migrate.

Your suggestion of keeping chan_sip active for people to select as their primary SIP driver is actually adding to the problem of getting people to migrate off of chan_sip.

21

Your recommendations for chan_sip come with vague claims of pjsip bugs, “not ready”, and etc. Yet when pressed to show the bug reports, there aren’t any. A chan_sip recommendation would hold a lot more weight if you actually showed the open bug ticket(s) supporting your reasoning for using the deprecated driver.

Please link tickets. And then when the bugs are fixed, future readers can see that the recommendation was made while there was a bug but that it was resolved and is no longer an issue.

5 Likes
22

Is that all that I needed to do? Here you go:

https://issues.asterisk.org/jira/browse/ASTERISK-28793?jql=text%20~%20"pjsip"

I only post recommendations that people try chan_sip when people post a comment stating that they’re having trouble with pjsip. Using chan_sip when you have trouble with pjsip is always a good trouble-shooting step.

There’s a post on the forums right now about a pjsip bug relating to NAT. And it is a bug that I’ve seen myself. Here’s one:

Thanks for giving me this chance to convert you. I assume that you’re in my camp now that I’ve given you precisely what you asked for! :slight_smile:

24

Unfortunately, I don’t think this will ever be possible due to mostly security concerns. Instead may I ask what part of Sysadmin should be open source?

1 Like