Suggestions for future versions of FreePBX

You are the first person to bring that up, and I agree that we should not conflate things that have nothing to do with our current discussion.

Well the forum post you recently linked to has nothing to do with this discussion either. The contact having the local LAN IP instead of the WAN IP could be due to a configuration issue. I see that someone asked to have the output of the transports to confirm their setup but no reply back on that yet. So this problem could be as simple as a user not setting up the proper details in their configs. Until otherwise shown, there’s no proof of anything related to a “bug” with chan_pjsip.

Also, you keep saying that chan_pjsip is new and not mature. It’s eight years old within Asterisk, 16 years old on its own. Chan_PJSIP is as currently almost as old as Chan_SIP was when you totally accepted it was mature and no need to be developed further. I would kindly ask you stop saying things like this as they are incorrect and misleading.

That report was of an intermittent problem. A FreePBX configuration error, or even a FreePBX bug, would not cause that.

But, now that you mention it, I do agree that bugs in the FreePBX pjsip module are also a good reason to keep chan_sip around.

You’re comparing apples and oranges.

chan_sip has been used in Asterisk and FreePBX since day one. Pjsip has not. The argument that pjsip is 16 years old “on its own” is irrelevant. What matters is its maturity on this platform.

Alright, this has become a circular conversation. I’m done with it. You should be prepared for people to be flagging your posts that have inaccurate information on chan_pjsip.

1 Like

The arguments have all been presented and hashed since the early days of FreePBX 13 when the decision was made to bind pjsip to 5060. When judgement is applied about how to proceed, you will always have differences of opinion. I would hope that when people advocate for a particular course of action, that they recognize that it’s their opinion, and that others have different perspectives and different opinions.

I will state categorically that the future of the project is pjsip. And I will state (again!) that chan_sip will be supported as long as is practical, but it’s not a project goal to support it indefinitely.

1 Like

Just my opinion on this issue:

In general, pjsip works fine with endpoints but has problems with some trunking providers and interface devices; there are of course a few exceptions.

For many users, pjsip’s ability to handle multiple registrations is a major benefit, allowing them to have multiple devices with the same extension number. It is also far more robust with mobile apps that switch between local and push server registration and/or between Wi-Fi and mobile data.

Many small systems are on-site with dynamic IP addresses and flaky internet connections. The inability of chan_sip to properly handle DNS SRV records and DNS failures makes pjsip the obvious choice.

Of course, pjsip lacks certain features (tel URI, identify by port, etc.) that renders it completely inoperative with some trunks and devices. Obviously, these should use chan_sip.

IMO problems with using both drivers are very rare. I’m aware of only one provider (Vitelity) and only when used with IP authentication, where the PBX must bind to port 5060.

All of the above relates to features. Bugs are a different animal. I’ll admit that pjsip is presently inferior. There are two open threads about Contact headers intermittently presenting an incorrect address. These guys are in different countries, with different providers and different firewalls. Unfortunately, neither has been helpful in tracking down the bug, so it’s hard to get it fixed.

One thing about this is it gets you closer to key systems which a lot of smaller businesses like

Can you clarify what you mean by “identify by port”? Within PJSIP, the identify support has supported identifying including based on port for awhile now. I don’t know if that’s what you’re referring to, or if supported by FreePBX.

Yes, FreePBX supports it because the PJSIP Trunk fields offer a text field to put in IPs to match against for incoming calls. It probably doesn’t denote that you can do 1.1.1.1, 1.1.1.1/28, 1.1.1.1:5060/32, 1.1.1.1:5060/28.

Yes, there are some things that are missing in chan_pjsip such a tel uri support. That type of thing was most likely deemed a small percentage of use and could be added in the future when there is a demand. I do agree that demand is growing so it could end up being in there. I mean it took until 16.19 or so for the RFC4325 issue to be addressed (proper XML data for NOTIFYs for call pickup). Been working great with the patch and after the patch was brought into mainline. At the same time new things have been introduced in chan_pjsip over the last three releases and FreePBX still doesn’t do anything with them.

So I think this does highlight a big qualifier for this discussion and that is how FreePBX is handling Chan_PJSIP. Because those of us that are using chan_pjsip in a pure Asterisk environment are really not seeing most of the issues using it in a FreePBX setup would.

Honestly, when I started to get as much on PJSIP as possible 3-4 years ago my biggest problem with PJSIP was FreePBX. Once I abandoned FreePBX’s methods, did everything in the custom files and did my own configs, PJSIP work way better and was easier to deal with.

Tom, I’m not sure if you still feel that way, but this is why I suggested moving the pjsip module more towards the way that the chan_sip module works, by creating an open field like the PEER details.

Doing it that way is also a lot faster if you have do to a bunch of different trunks, because can just cut and paste from one source instead of having to input multiple fields on multiple tabs.

(This reminds me of the debate about the “dialed number manipulation rules” changes from 6+ years ago).

And again, this is why it is not yet time to disable chan_sip by default. That day will come. It is not here yet. :slight_smile:

Care to elaborate on that?

The problem with this is that feature requests on the Asterisk JIRA are rejected from community members unless they include a patch. This is not helpful; many end users are quite adept at reporting legitimate bugs and feature parity issues with chan_sip, but don’t have the programming skills or the time to actually write patches to support the development of PJSIP. Closing the tickets prevents us from even getting to first base.

The better option is not to use chan_sip, but to open a Feature Request in Asterisk JIRA, and post a bounty or find someone to write the patch.

Everyone needs to remember that this is an OPEN SOURCE project. As a community, we are getting something for free… If you don’t like something then contribute. Complaining about PJSIP is inappropriate IMHO. Let’s all work together to do this right. The code for chan_sip is horrid and the PJSIP rewrite is long overdue.

1 Like

I’ve been mentioned here several times now, and I think I need to speak up as well. It’s about the issue I have with PJSIP and NAT.

First of all I have to declare that I’m not as professional as you all might are, so please be tolerant with me. I cannot say for sure if my issue is a bug, a misconfiguration or even something else.

@Stewart1 I don’t think it’s fair when you say I’ve not been helpful. The problem with the issue is that it’s very intermittent. Since you asked me for logs of when the issue occurs, it didn’t happen again at all. Power cycling the modem didn’t work to trigger the issue so right now I can just wait for it to happen. But if anyone has an idea of what else I could do, I’m glad to hear that.

@AdHominem Even thought I do not completely agree, I think your opinion on removing Chan_SIP isn’t entirely wrong. When I started working with FreePBX I decided to use PJSIP because of a comment I found from @lgaetz that recommended using PJSIP. It worked for me most of the time, but I have to say that there is a lack of documentation on PJSIP. For me as someone who hasn’t worked with Asterisk before, it was much easier to setup Chan_SIP than PJSIP, especially about NAT.
Don’t get me wrong, I don’t want to say you shouldn’t use PJSIP. I’m using it myself, even though it’s not working as easy as Chan_SIP for me.
Why not disabling Chan_SIP by default on new installations but allowing to install it as a module if that’s possible? Wouldn’t that be something everyone could agree on?

Indeed, this is how it is in FreePBX 16. (Try the beta!)

I don’t think I would agree on this, at least not entirely.

Documentation in the Asterisk wiki is quite good, though most FreePBX users are not digging into the Asterisk wiki.

chan_sip has been around a while and you will find documentation in the form of tutorials, blogs, wikis, and support forum materials going back almost 15 years. Because it has been around longer, there is more such documentation, for sure.

PJSIP in FreePBX is a little more self-documenting. For example, with a chan_sip trunk, you are presented with a Peer textbox where you had to enter the config. A PJSIP trunk gives you labeled, tool-tipped fields so that you can understand and configure each setting. This is far better than an open textbox.

As I’ve been saying for years, your comment is not only true about pjsip - it is true about the entire project as a whole. People will point you to the wiki, but if you take a look at the wiki, you’ll find that it is a jumbled, disorganized mess. For some parts, there’s nothing. For others, the information is grossly outdated.

If you check the links in the Module Admin module for FreePBX, you’ll find many of the links to the Wiki are broken.

The Wiki entry for the Trunks Module is an example of a disorganized mess. The section on pjsip is clearly an afterthought, with useful nuggets like “Retry Interval - How long between retries,” but no explanation as to WHAT is being retried (most likely it is registration).

https://wiki.freepbx.org/display/FPG/Trunks+Module+-+User+Guide

There are some nuggets in the Wiki, but there are a lot of pages that contain no useful information whatsoever, or are filled with jargon.

The tooltips in FreePBX are also hit or miss. Some are quite useful. But, some are really nothing more than taking the field title and rewriting it in a sentence. In other words, if the title of the field is “Field Title” the tooltip might be “Sets the (Field Title”). Uh, thanks.

Early in the project, there was even less documentation than there is today. Since the product is free, a lot of people wrote extensive, step-by-step how-tos. Two of the greatest writers were WiseOldOwl and MichiganTelephone, but both of them eventually just gave up because the rest of the community were so hostile to them that they couldn’t stand it anymore. MichiganTelephone had a great blog that you could follow step-by-step to set of an amazing open-source FreePBX without having to ask anyone a single question, but he deleted the whole thing in disgust. Here’s what’s left:

I took up the torch for a while and wrote a lot of stuff for the Wiki. Tony Lewis even offered me the job as Community Manager, but I turned it down because my day job is better. He hired someone else who came in an butchered much of what I wrote. You can see his influence in the Trunks documentation that I linked to above.

For comparison, you can see the Trunks documentation that I wrote here:

https://wiki.freepbx.org/pages/viewpage.action?pageId=20152464

(Note that GUI changes made to FreePBX by the devs made the screenshots that Included obsolete.)

And here’s the article I wrote about linking two FreePBX systems together, which the new CM left intact for some reason:

https://wiki.freepbx.org/pages/viewpage.action?pageId=4161588

@billsimon I’m honest, I never worked much with the Asterisk Wiki. It feels a bit overcomplicated to find information there. Just using a search engine seems often much easier for me.
What I often missed was the answer to the question ‘What is best practice?’. With trial and error I can make most things work, but it would be great to know how things are intended to use.
My view of PJSIP seems to be a bit different than yours. I just wanted to explain my first impression as someone who hasn’t worked with FreePBX or Asterisk before.
I also like how the PJSIP Trunk Settings are made, just the General PJSIP Settings seem to be more complicated than the General Chan_SIP Settings. For me especially when it’s about Dynamic IP addresses, NAT or DNS SRV.

@AdHominem When you’re talking about that Wiki it feels like you’re very hurt by what happened to the parts you’ve written.I respect that you feel like this, but I wouldn’t be that harsh. I also cannot entirely disagree. I think the main problem is that documentation is important but it’s also really hard to keep it up-to-date. The versions which are sometimes so different make it also very complicated to work with the Wiki.

By the way what I really enjoyed to read was this post from @lgaetz which I think would be great for the Wiki

My view is that the people in charge can do whatever they want with the Wiki. I knew that was a risk when I chose to contribute to it.

I remain worried for the project though. Good documentation is essential allow new people, like you, to participate. And without new users, the project will eventually die, which would be a shame.

Though I haven’t yet abandoned all participation like WiseOldOwl and MichiganTelephone did, I’m certainly not planning to write anything more for the Wiki. It’s not that I’m hurt, it’s just that writing for the wiki would not be productive use of my time: If what I write gets deleted, then the benefit I was hoping to confer on the community won’t be there - so why bother?

It would be easier to keep the documents up to date if the Devs were more careful about keeping things consistent from one version to the next - to the extent possible. While I totally understand that new versions need to have new features, a lot of the changes between versions have been cosmetic. Cosmetic changes break the documentation.

Another way to solve this problem would be to require that if a Dev wants to make cosmetic changes, that same Dev is required to update the documentation. :slight_smile:

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

Not seeing a lot of value here. Everything has been said before, it’s clear where people stand.

Locking thread.

4 Likes