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