PJSIP still has bugs

How about a pjSIP trunk configuration for VoIP.ms with a PBX bit behind NAT?

I beg to disagree, PJSIP is by far not mature enough to use in production. I don’t know why this is a taboo-like issue, PJSIP doesn’t work at 100% that’s it period, No one is offending no one, no one is saying that Digium is not working on it, etcetera etcetera. I still not pushing any changes on new or old servers to use PJSIP because simple things like BLF doesn’t work as expected.

I don’t understand why everyone took it personal and start saying Dicko’s opinion is wrong also the sentence: [quote=“mbello, post:22, topic:42178”]
What was going on in dicko’s mind?
[/quote]

It’s kind aggressive, I mean should I ask your permission first to say something? Do you need to approve what’s in our mind? Or just because we think different than you we are wrong?

Use the wonders of google and you will find that many people are having issues and dropping the use of PJSIP.

2 Likes

@navaismo

All I wanted was the name of a provider. Dicko could not provide that. Nor could he provide what was actually wrong. It’s unfortunate you think it’s ok to just state “pjsip is very buggy” without actually saying what is wrong. You are a developer. How would you feel if people said " @navaismo software is berry buggy". Yeah digium is working on pjsip. But the idea of it being very buggy is news even to digium so if you or anyone feels that way then let’s report some bugs. Just saying it’s buggy doesn’t help anyone. I am baffled you agree with this logic.

Saying “use Google” to find pjsip bugs is a lazy response.

I have been using PJSIP (in conjunction with chan_sip) for years with all the phones, soft phones, ATAs and trunks at my disposal. I have devices from Sangoma (obviously), Yealink, Grandstream, Aastra/Mitel, Digium, Cisco, Obihai, Snom as well as a few SIP trunking services, and I have NEVER had serious issues with PJSIP with anything other that the YATE Softphone. In my usage, I can pretty confidently say that the PJSIP driver is solid. I am personally aware of large FreePBX deployments (hundreds of peers) with the chan_sip driver disabled, they work fine.

There are issues though, and many of these take the form of FreePBX integration. Every month or two a ticket appears that identifies a specific pjsip parameter that needs to be exposed in the GUI, or some weird corner case comes up in support that can’t easily be explained, so we try chan_sip and find it works. Whether someone wants to then do the necessary research to figure out what is going on or just abandon pjsip depends on their patience and knowledge level. Until you go through the effort to figure out the exact mode of failure, you can’t say there is a bug in either the driver or FreePBX. I have seen a few credible reports from knowledgeable users that take the form “pjsip doesn’t work with X device”, but with no more information than that it is irresponsible to say there are bugs in pjsip or FreePBX when it could just as easily be a phone firmware or config issue.

When someone posts a problem with PJSIP, the recommendation will first be to try chan_sip. That is a reasonable diagnosis step, but need not be the final solution. If chan_sip works, then it will be up to the user and their knowledge level to continue the debug and determine why one works and the other does not. Human nature being what it is, most will opt for the easy solution, but the product is only furthered by putting in the extra effort and identifying issues for the benefit of future users.

4 Likes

I myself agree, that was intended as a reply to a poster having trunking problems over PJSIP. For the life of me I can’t find the original post. I composed it on my phone and I am an insomniac, and possibly stumble fibgured,

Otherwise I agree, any one who started such a thread should be bought to task if it lacks context.

Edit, I notice my ‘original’ post in this thread was edited and

Mod edit: this was taken from New installation reload failed still

Was added.

It would have been less misleading if that had been done when split, akso where I the Mod, I would have chosen a less polarizing title. But thank you Mod. For clarifying.

Hi!

And that’s not what he did… Those messages were split from another thread…

Please look at the second line of “dicko’s” first message on this thread…

You mean Andrew’s mind (I am pretty sure he is the one who split the thread)…

This was going too off-topic for the other thread so it was split, I would have done the same thing if I could have…

Some people here obviously have a different experience with it than you do and unless you tell me that those two PBX have entirely different phones, endpoints, etc… For now, it simply means that you one of the combination that works…

Interoperability is not always perfect between implementations of the the same protocol (ie PJSIP)…

Heck, for a simple thing like emails it was (and is quite likely still is possible with some MUA (mail clients)) to have pretty weird problems is some situations.

e.g.

We had a pretty weird problem at work that, when some people would send emails, if someone were to reply to them the reply would, possibly, get sent to multiple people…

It turns out it was misinterpretation of how to encode some email headers (this time it was the “From:”) when special characters (accents, diacritics, etc…) were needed in them and when a comma was present…

Not everyone had interpreted the standard (actually a RFC) in the same way…

At the time Microsoft and IBM products were implicated in the specific problem we had at work… Surprisingly Microsoft had gotten it right (or pretty close to) and IBM had gotten it partially wrong…

I could have stopped there but since I was using Mozilla Thunderbird I tried it with it and noticed they had the same problem (IIRC, it was even worse).

I actually enlist the help of the RFC (standard) author to get them to fix the problem as they had initially closed my ticket even when I said I had consulted with him before to ensure my interpretation of the RFC was right…

They were absolutely convinced they get had gotten it right until the RFC author proved them wrong…

When there are interoperability problems or errors in the implementations you have

  • To actually find them (or let them find you :wink:).
  • Report them and be ready to “fight” for them…

Now the problem I had at home with Thunderbird I could wait for it to get fixed but the one at work with Microsoft and IBM I could not…

If there had been such a simple solution such as switching from one stack to another I would gladly have…

That doesn’t mean I would not have reported the problem to them, I would have, but I would not have continued to use it…

That doesn’t mean not using PJSIP in a controlled environment but be aware of possible problems with it, problems you won’t have with the more mature (but less maintained I believe) Chan_SIP…,

I am no SIP/telephony guru but many of them have spoken about this now, enough for me not to consider lightly using PJSIP…

I disagreed with something someone said earlier in this thread which suggested what I did not understand what the problem was about.

I certainly did… For me phones or providers it makes no difference, it’s the same protocol… Some things might change but the underlying protocol stays the same…

At the time I did not reply because it seems like one “side” will not be able to convince the other one there is actually a problem and this thread, at least back then, seemed like it was going nowhere…

Have a nice day!

Nick

1 Like

Hi Andrew!
I hear you, but also I understand the other point of view. I don’t know if Dicko or anyone else are able to report bugs, to make traces or generate the coredump file and create an issue on JIRA so that’s why I “understand” the “buggy” sentence. Then I should expect from devs from here and from there asking helpful question to create this issue in JIRA or just end by the “Layer 8 issue”, but no an attack against the user who is complaining about the issues.

You know that I was trying to use the new channel since the GULP creation, so far I’m not very comfortable with the new channel, and I don’t have the time to do the research and provide bug trackers so yes was a lazy response indeed, but not an invalid one.

@lgaetz I’m not even talking about FreePBX all my (ex)servers are plain asterisk, and yes found issues.

So back to the topic we should help people to understand and to create real bugs statements before attacking them and make feel the other people is wrong just because the things that we use works for us and not for them. Maybe dicko was using the aggressive way to get help instead saying “I have an error here and here” he use the “stupid software doesn’t do that” expecting the “You are a fool it works if you do this…”

Anyway I will give it a try later to the new PJSIP channel and I’ll let you know if still very buggy or if now i can eat my words :slight_smile:

I think you need to go back and read this thread in full. I asked.

I edited that in there 5 seconds after it was split. This is not new. It’s been there since this topic was created.

This is shameful! A thread gone to crap because were all acting like kids arguing about who said what. Lets be adults here folks and just move on. This is an adult forum!

Back to the topic about PJSIP being buggy:

I too have encountered issues when trying to work with PJSIP. Enough that moving back to Chan_SIP fixed the issues. My problems were BLF monitoring was not working and occasionally my phone call would not connect to the phone server. Every now and then i would even get the red slash through the lines and then they would connect again.

Also I once worked with a Sangoma support staff member and he told me that PJSIP had issues and he ripped PJSIP out of the PBXact device completely. This was less than a year ago. That came directly from a Sangoma Tech. I dont recall his name, but to go as far as disabling the channel all together to solve the issue must mean something. Its honestly not that big of a deal, but i took heed to his words and always stick with chan_sip because of it.

Phone systems are so diverse and PJSIP introduces some pretty complex elements, even if it has been out for years, it DOES still have some issues in some cases. I have experienced it, I guess more importantly what would the argument be as to NOT use chan_sip. What does PJSIP give me other than multi-registration for an extension.

It’s supported by Digium. Chan_sip is not supported by Digium. They don’t fix bugs in it.

I will once again go to Astricon in October and when they ask about community issues I will state that our community thinks PJSIP is buggy, when they ask me specifically why I will have to say “I don’t know, they just say it’s buggy, I have no tickets or issues or proof”. Or maybe I just won’t say anything about it.

Edit: This comment means no harm or ill-will to the community. I can only present based on the facts that I have.

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?

2 Likes

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.

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.

2 Likes

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.

Summary:

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.

1 Like

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.
http://wiki.voip.ms/article/Registration_issue#ATA.2FSoftphone

1 Like

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.

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

1 Like

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.

4 Likes

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

1 Like