Suggestions for future versions of FreePBX

[AdHominem]

@BlazeStudios

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).

@Stewart1

I’ll admit that pjsip is presently inferior.

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.

[BlazeStudios (Tom Ray)]

@Stewart1

I’ll admit that pjsip is presently inferior.

Care to elaborate on that?

[yois]

@jfinstrom

If there is some feature parody missing open a ticket

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.

@Stewart1

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

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.

[AdFun7911]

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.

Incorrect IP in contact header

When connecting to FreePBX via PJSIP from outside the local network everything works just fine most of the time. But every now and then there is no sound on all endpoints. There are sometimes weeks in-between that problem occurs. After a reboot or typing fwconsole restart the problem is gone but that’s not a solution. I was able to figure out that FreePBX is using the internal ip address in the contact header instead of the external ip address. I don’t really understand why this is just happe…

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?

[billsimon]

@AdFun7911

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!)

@AdFun7911

there is a lack of documentation on PJSIP.

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.

[AdHominem]

@AdFun7911

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.

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:

This is not the blog you are seeking

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

[AdFun7911]

@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

Hooking for fun and income

Despite the frequency with which it arises here in the forum, there is not yet a good resource for learning to use dialplan hooks in FreePBX. This will probably end up in the wiki at some point, but until that happens, here are the broad strokes for leveraging dialplan hooks in FreePBX 14. What is a dialplan hook? A dialplan hook refers to several pre-defined FreePBX contexts that exist solely for users to add their own Asterisk Macros to be run at specific locations in the call flow. They all …

[AdHominem]

@AdFun7911

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.

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?

@AdFun7911

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.

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.

[tm1000 (Andrew Nagy)]

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

[lgaetz (Lorne Gaetz)]

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

Locking thread.