I really like this answer.
In the newest versions of FreePBX/Asterisk, you have to install and enable PJ-SIP to get RTP to work correctly, so there’s that…
While Chan-SIP is, indeed, on it’s way out, remember that it keeps saying “I’m not dead yet!”. Someone is definitely going to have to bop it on the head to shut it up. Having it installed for the off-case where it’s the way to go, you have it. Don’t fear it - use it.
Not knowing any better, I built our FreePBX 14 with pjsip, extensions and 12 channel spectrum trunk. no issues.
Nice to see that most of you doing it the same way,
i am also using pjsip for ~3 years.
pro:
con:
I use pjsip. Had to change one trunk back to sip. I don’t need to be a trailblazer and debug anything. The others all just worked and are stable.
I created an another issue today because my phones change to state “unavailable” after some reloads of freepbx when i use PJSIP. I created about 20 extensions with UDP/SRTP today. After all about 5 Extensions i created, i reloaded freepbx with the red Button.
After 3 Reloads, sometimes after 5 or more my registrations to the phones are dropped and all phones get unavailable.
Phones: Sangoma S500/ Sangoma S700 / Snom M700/ Yealink T46S/ Yealink T56A / Grandstream GDS3710.
Hosted KVM in the Datacenter with it’s own Public IP.
Using Responsive Firewall. Client IP Adress where my phones are is whitelisted.
I have no idea anymore. There was an open ticket on asterisk as well but cannot find it anymore.
https://issues.freepbx.org/plugins/servlet/mobile#issue/FREEPBX-17662
Is that only happening to you when using TLS and SRTP?
That is the question. Until today i thought it is only with TLS. Last year i installed a customers PBX with PJSIP without any encryption there i also switched back to Chan SIP because of the same Problem. After a few reloads the extensions get unavailable without any reason. At this time it was Just UDP but i thought it was fixed but it isnt as i can see today .
Are you doing reloads right after each other. If so my guess is CPU gets overloaded and you never let it calm down and after awhile asterisk can’t keep up because it has no CPU cycles to deal with anything. Bet the same thing happens in chan sip
I recently ventured into PJSIP as well, converted 30% of the extensions and most trunks on one of my HA installs to PJSIP, but backed out two weeks later after people complained to me about unusual audio issues and phones being unreachable. I had no proof that it had anything to do with pjsip, but still pulled the plug, reverted back to chansip and things are back to fine since.
I don’t like using both drivers simultaneously, it’s cumbersome and makes troubleshooting more difficult, and I would prefer to move to pjsip entirely. I will probably give it another try next year.
No it only happens with PJSIP.
If i use both technologies together then only the PJSIP endpoints get unreachable spontan from time to time after a reload. Each reload had a minumum 2 minute waiting period.
Machine:
KVM with 4x intel xeon2620 cores and 4gb RAM. I tested it also an the same machine with only a few extensions installed on it. It happened also.
I’m going to be very honest with you all. When you go and open a ticket up about PJSIP issues on the FreePBX issue tracker that are about issues which have no logs, no debug of any sort (the auto responder basically begs you to add logs and debugging) AND the issue is about something that FreePBX has almost no control over it’s very hard for the development team to replicate. Of note we use PJSIP internally and also externally and we haven’t seen any of the issue you mentioned in your ticket which only further adds to use not being able to replicate.
I see that maybe there is a lot of finger pointing between Digium and Sangoma here but when a reload happens write merely write out configuration files and then tell Asterisk to reload. There is no other fancy logic we would be able to control here with phones not being able to register.
Your best bet would be going to either our Commercial Support or Digium’s commercial support. Either would work for you.
You see the only practical thing we could do from that ticket is working on your system directly. Because again it’s not reproducible. We are not allowed to do this on open source tickets. This is because if we go in and muck around with your system and break something Sangoma is now liable for damages. When you go through our commercial ticket system you agree to terms of service.
What I don’t like doing is assigning a ticket like this out to anyone, as it consumes resources (I already reloaded the system a few times and my phones stay registered each time). It consumes resources because it doesn’t do anything but sit in our tracker and collect dust.
Therefore I closed this ticket. Really there is nothing more we can do. As the ticketing system states, “tickets are for reproducible issues”. We try to reproduce every ticket we run across. If we can’t reproduce it we have to close the ticket. Especially if it’s something that has a ton of variables. The ticket itself was named “PJSIP - all extensions “Unavailable” after some “Apply Config” reloads”
As far as I know, “Unavailable” points to exactly one thing, an OPTIONS packet was sent from the PBX to the endpoint, and the corresponding 200 OK was not received as a response. This is 100% SIP signalling, RTP is not involved. There are a number of reasons why the 200 OK might not make it to the PBX (apart from the obvious that the endpoint just doesn’t send it) such as: network routing, SIP ALG, firewall(s), NAT misconfig of PBX or endpoint, probably others. PCAPs taken from the PBX, router (if applicable) and/or endpoint should reveal whats going on.
My experience with PJSIP: I converted 2 extensions to PJSIP because of multi-device support about half an year ago. There were no problems until last week when suddenly PJSIP phones lose their registrations. Regular messages in the log (about once/hour) stopped appearing. netstat still showed that asterisk was listening to UDP port 5061 but there was no response from asterisk to Register messages. Asterisk uptime was nearly half an year! fwconsole stop/start solved the problem. Apperantly SIP is still more stable than PJSIP. 
Are you talking about when you reload the BLF lights go off and registration on the phone dies? If so have about 1000 active extensions on out server and about 2000 built extensions with that. Chan_sip does it as well as PJSIP but chan_sip seems to appear like its still working even though its not while PJSIP shows its not working when it isn’t working.
It seems to happen when the BLF’s are being rebuilt after the dialplan gets fed into asterisk. It takes a little bit depending on your machines speed to rebuild it thats why you probably have that 2 minute waiting period.
fyi, i have been battling this for a long time
https://issues.freepbx.org/browse/FREEPBX-14468
https://issues.asterisk.org/jira/browse/ASTERISK-27148
although this started for me on FBX13, it continued through v14. to be honest, the problem stopped about 2 months ago after some updates, i never got an explanation and had a hard time convincing anyone that this is a real problem…
good luck, and make sure you update.
Anyone , with any news 1 year later ?
Thanks
News about what?
if the PJSIP is better now after 1 year and less bugs etc …
as the thread Chan_SIP vs PJSIP …
Like I said over a year ago…
Certainly better, certainly fewer bugs.
To be honest, some “bugs” are due to lack of understanding of pjsip.
You will need to enable pjsip if you want to use FreePBX’s webrtc and Zulu solutions.
There is not really any reason now to hold back. PJSIP has been part of asterisk for like 5 years. It’s not “new”