PJSIP still has bugs

Tags: #<Tag:0x00007fafc6b62920>

(Jessy5765) #34

This is seriously the response you give? While I can appreciate and already read the first part of it up above the 2nd part is total bullshit! If I ever spoke to a customer of mine that way I would be fired!

I see your point, I understand the frustration but you have to understand that most of us here can only mention the issues we are having we can’t afford to have clients breathing down our necks while you guys resolve the issues. Our solution is to failback to what we know works. I stated what my issues were but I guess the fact that one of your employees ripped it off of a PBXact server means nothing after saying it had issues. Maybe internally you guys need to align on your answers. We are trying to help but responses like this make me want to go sell something else.

Edit: Next time I do a phone deployment I will do a FULL PJSIP deployment and see what pops up. If anything comes up I will enter a ticket, but i want fast response to it to start troubleshooting after I do my basic troubleshooting. Can that be agreed?

(Lorne Gaetz) #35

I’ve read and re-read the paragraph in question and I genuinely don’t see anything there that can cause offense. It is a plain statement of fact. If you browse open PJSIP FreePBX tickets at present, you won’t find any show stoppers, just feature requests and edge cases. I guess if you happen to be the one affected by one of these edge cases, you may well consider that a show stopper, but there is a decided disconnect between conversation in the forums and actionable tickets in the tracker.

(Jessy5765) #36

I was referring the snarky comment at the end that’s all. Pretty much calling out the community that we say there is issues but no proof. Its a bit disrespectful to us almost as if we are full of shit and he keeps saying over and over again there is no issues with PJSIP, yet we say there is. tldr: Were stupid and don’t know what were talking about.

As for the tickets, again, your right, we arent reporting them as we should. No one can argue that. :slight_smile: But like I said, if you truly feel that there is no issues I am installing a PBXact tomorrow that is a 3 site 14 phone system using S700’s. I will use PJSIP and report back my experiences.

(Andrew Nagy) #37

You are readying between the lines. Let me try to clarify since you now believe I should be fired.

Last year at the Asterisk Developer conference I brought up the fact that this community still feels that PJSIP is largely very buggy. The Asterisk developer team (my opinion) was slightly shocked by this statement as they didn’t see that from their bug reporting system. Now we have a thread here that is basically doing the same thing. Saying PJSIP is buggy and I have no reliable way to show them in which or what way it’s buggy.

That is what I mean by that I never once said “[you are] stupid and don’t know what [you’re] talking about.” nor did I mean to even imply that.

The fact of the matter is that I will be going back to Astricon and I will say that this community feels that PJSIP is still buggy and that they won’t use it but I won’t have any facts to back that up. That’s very unfortunate, as it was last year.

Sorry that you read what I said so differently from how I really meant it.

Not at all. I believe you. I do not agree with “PJSIP is very buggy”. However this is a he said she said type of argument. I am merely asking for the bugs, so that I can report them. I am not saying you are wrong or that I don’t believe you (I don’t think I said that anyways)

You call me out for saying “over and over again there is no issues with PJSIP” then right after that you say “As for the tickets, again, your right, we aren’t reporting them as we should”. Slightly contradictory? No?

So let’s try to get back on topic and please stop thinking that I am telling you that you are wrong, I am not. I am asking for reliable information that either I can pass along to Digium or that I can present to them when I go to the conference. If you can’t provide that then what’s the point of this conversation to begin with.


Everyone I hear what you are saying. But we need proof to present to Digium. So when you experience a PJSIP issue report it on the Digium tracker. Then you will have “proof” (facts, reliable information, whatever you want to call it) that PJSIP is buggy and you can pass it around as FACT not OPINION.

Again. I didn’t say this. I am debating the fact that the statement “PJSIP is very buggy” is nothing to go on.

(Jared Busch) #38

PJSIP works great for me from end points with a PBX on prem in hyper-v and multiple PBX installs on Vultr. Generally with Yealink phones.

PJSIP default registration timeout causes trunk failures with VoIP.ms

If you change the registration expires setting to 120 seconds, as recommended by this old CHAN_SIP troubleshooting guide on the VoIP.ms wiki, the problem goes away.

(Jared Busch) #39

There is a known issue with Yealink phone and PJSIP.

I worked with Yealink support and found a setting to be changed instead of hacking it by killing packets in the firewall.

Bug report I submitted for EPM has not been touched. But this could potentially be something for digium. I dunno, because I don’t know the PJSIP standard to know if Yealink is doing something wrong or if PJSIP is. I just know the setting specified made the problem go away.

(Jared Busch) #40

Those two problems are not indicative of very buggy or unstable. They also both have solutions.


Wow, big discussion!
Here’s my gripe with how PJSIP is implemented in FreePBX. It should have been implemented by Digium in AsteriskNOW, not pushed to every single end user in the mainstream FreePBX distro. We all like to say “well that’s done so move on”, but I think the fact that people are still, years later, saying PJSIP is “buggy” is a clear indication that the UI just doesn’t cut it in terms of making the driver usable. From my work in IRC, I know for a fact that a huge part of this is NAT configuration; most people come from setting NAT to yes/no/route/etc, and now none of that’s there and it isn’t clear from the UI which options need to be changed. That alone can lead to so many false positives in terms of “bugs”, as it’ll manifest as any number of things.
The other half of this is that I’m not interested in beta testing Digiums new channel driver. I can do so on my own time, little by little, but that just isn’t my role, any more than it’s Andrew or Rob’s roles to sell systems. I don’t have the capacity to do it. That leaves me with not a whole lot of options; unfortunately, it basically forces me to use chan_SIP until what I need is worked out. Yes, the issues I’ve encountered exist as bugs. No, I don’t have anything new to add.
If you’re going to bring something back to Digium, I’d explain to them that the decision to implement the new driver before Digium themselves did so in AsteriskNOW was a mistake and it has caused some nasty grief while people adjusted to the new learning curve. I’d love to use it primarily; not only could we sell more stuff, we’d be current with what Digium expects, and the functionality at the phone is just better. Unfortunately, every single time we implement it we inevitably come back to chan_SIP because of some problem we can’t get around and don’t have time to sit on and debug. Little things, like the inconsistencies between CLI commands for chan_sip and PJSIP are irritating. Bigger things, like TLS configuration within FreePBX, are weird and I don’t even know what to look for in terms of documentation. In all, it feels like an unnecessary burden put on resellers, something that could have been avoided. The change from chan_sip to PJSIP will not impact individuals almost at all. It will/has impacted resellers with an already limited amount of resources. I wish that had been considered prior to the change.

That should not come off as ragging on either Digium or the FreePBX developers. Just trying to explain my own frustration with the situation. I’ve largely resolved it by avoiding PJSIP in my deployments whenever possible, but I realize that at some point we’ll need to change that, and we’re putting work into testing what we need to make that happen.


Here’s one to add to the list: chan_PJSIP does not have an equivalent to the ‘externhost’ functionality.

The number of users with dynamic IP’s is in no way a small number. New users regularly visit IRC who are using some sort of DDNS in conjunction with the hostname field in SIP Settings. You also have a large home user/hobbyist group without static IP’s at home. I actually have locations where paying for a block of static IPs on a business line was unnecessary, and opted to use DDNS.

When I asked a core Asterisk dev about this missing feature, I was basically told “We’ve never discussed adding it and i’m not sure who would use it”.


Great! Two issues solved so not “buggy” let’s pretend this never happened ( ¬ ¬) And People on IRC, spanish forums and sometime stack overflow are overreacting.

I just want to say something for your consideration(for everyone not just you): How come do you expect that an user who is using a GUI to make things easier and not dealing with the bare-bones of Asterisk create a complete debug and a ticket into JIRA, let’s be honest FreePBX was built for those who doesn’t have an Idea of anything and just want to click here, click there and PUM! PBX up and running. ¯\_(ツ)_/¯

Keep in mind that in my case I’m not saying “Go back to chan_sip” nein, I just want to PJSIP be more mature and less weird, if you make a dive in the Asterisk forum you can see many posts about PJSIP and also many responses from JCOLP actually solving issues, many times from miss-configuration.

No one likes salty trues from both sides, in my case I will still using chan_sip or maybe start the migration to OpenSIPS and leave asterisk only as a media handler but for now there is “No satisfaction” using PJSIP although looks promising.

( Then again I should start using it and report the “buggy” issues to make it more usable… but the age and the time you know :stuck_out_tongue: )

(Avayax) #44

I agree.
E.g. every enterprise with Comcast/Xfinity internet service using third party modems will only be given dynamic IP addresses.
In our case the default Comcast modem didn’t work properly using a firewall behind it, so we needed to replace it.

(Andrew Nagy) #45

After talking with you in IRC about a year ago we changed the default on new installs from PJSIP being on 5060 to chan_sip being on 5060.

(Tom Ray) #46


Yes, that did happen then after much debate it seemed to go back to Chan_PJSIP on port 5060. I’ve installed dozens of FreePBX systems in the last 12 months in ALL cases I’ve had to change the ports on Chan_PJSIP and Chan_SIP to make it so Chan_SIP is 5060.

Here’s two that still had the Dashboard warning from the ones I’ve installed in the last 12 months.

(Andrew Nagy) #47

We JUST built a new Sangoma 7 distro (that image above is from a new install) and chan_sip is 5060. Not sure what you are installing.

(Tom Ray) #48

So this didn’t happen a year ago after the talk on IRC? Or did it just happen now? Your statement clearly infers that you changed the defaults after the conversation a year ago. My reply is based on that inference and thus shows in the last 12 months that has not been the case.

A year ago the conversation wasn’t about PJSIP defaulting to 5060 on SNG7, it was about the v13 distro. Stating that it is just happening now on SNG7 doesn’t really mean anything outside of only people who install SNG7 will see this. Not anyone using v13 distro, which is what the original discussion was all about.

(Andrew Nagy) #49

You are right. We didn’t change this. So nevermind what I said


Fake news! Thanks for clearing that up. I hope the rest of my comment makes sense, and provides more of a basis for you to begin to understand the problems many people see with PJSIP.

(Rob Thomas) #51

@tm1000 and I are on the phone, right now - and both he and I thought that we had changed it back, about a year ago, specifically as a result of the discussion on IRC.

(Rob Thomas) #52

Well, we were wrong. We had changed some TLS ports, but PJSIP is on 5060 if Asterisk 13 or higher is installed. Sorry for the confusion.

OUR confusion was the result of a bug in the 14 installer that thought we were ALWAYS installing 11, which is why chan_sip was always on 5060 for our recent installs.


I’m actually curious now; is chan_sip on 5060 in the latest version of the distro?