Hi All,
We have made a dessision switching our phone system from Avaya to Sangoma PBXact UC 2000
with all commercial modules and 600 sangoma 705 phones and 18 Vega 3050 gateways, I want to ask and see which protocol should i use to build all the extensions Chan_Sip or PJSIP.
Thank you
pjsip unless you have problems with it
Thanks @asteriskadmin i dont have any problem i just want to use the recommended one i have to create 1200 extensions and i dont want to create them twice
Thank you
Pjsip for sure.
We just tried this with 1200 extensions as well and it blew up in our faces. I think its the BLF portion that failed miserably but not sure. Had to switch back to chan_sip.
Make sure to have an âoh fuck what the fuck is going onâ backup ready.
It would certainly be nice to know because Sangoma/Digium is behind PJSIP 100%
I could tell you the conditions and what was happening but I canât do any testing or diagnostics for a while, that set us back a lot. If thatâs fine do you want it in a freepbx ticket or forum post?
Do it here.
This is all being done on a Cyberlynkâs dedicated server.
Server Details:
Freepbx Status before Switch
Phone Details:
Modules were somewhat close to this:
+---------------------+------------+-----------------------------------+------------+
| Module | Version | Status | License |
+---------------------+------------+-----------------------------------+------------+
| accountcodepreserve | | Not Installed (Locally available) | GPLv2 |
| announcement | 13.0.7.1 | Enabled | GPLv3+ |
| areminder | | Not Installed (Locally available) | Commercial |
| arimanager | 13.0.4 | Enabled | GPLv3+ |
| asterisk-cli | | Not Installed (Locally available) | GPLv3+ |
| asteriskinfo | 13.0.7.1 | Enabled | GPLv3+ |
| backup | 14.0.6 | Enabled | GPLv3+ |
| blacklist | 14.0.1 | Enabled | GPLv3+ |
| builtin | | Enabled | |
| bulkhandler | 13.0.14.6 | Enabled | GPLv3+ |
| calendar | 14.0.2.5 | Enabled | GPLv3+ |
| callback | | Not Installed (Locally available) | GPLv3+ |
| callforward | 14.0.1.3 | Enabled | AGPLv3+ |
| callrecording | 14.0.1 | Enabled | AGPLv3+ |
| callwaiting | 14.0.1.1 | Enabled | GPLv3+ |
| cdr | 14.0.5.14 | Enabled | GPLv3+ |
| cel | 14.0.2.6 | Enabled | GPLv3+ |
| certman | 14.0.2.1 | Enabled | AGPLv3+ |
| cidlookup | | Not Installed (Locally available) | GPLv3+ |
| conferences | 13.0.23.12 | Enabled | GPLv3+ |
| conferencespro | 14.0.2.3 | Enabled | Commercial |
| configedit | 13.0.7.1 | Enabled | AGPLv3+ |
| contactmanager | 14.0.4.9 | Enabled | GPLv3+ |
| core | 14.0.18.22 | Enabled | GPLv3+ |
| cos | | Not Installed (Locally available) | Commercial |
| customappsreg | 13.0.5.4 | Enabled | GPLv3+ |
| cxpanel | | Not Installed (Locally available) | GPLv3 |
| dashboard | 14.0.3.3 | Enabled | AGPLv3+ |
| daynight | 14.0.1 | Enabled | GPLv3+ |
| directory | 13.0.19.5 | Enabled | GPLv3+ |
| disa | 13.0.6.1 | Enabled | AGPLv3+ |
| donotdisturb | 14.0.1.1 | Enabled | GPLv3+ |
| endpoint | 14.0.2.145 | Enabled | Commercial |
| extensionroutes | 13.0.10.6 | Enabled | Commercial |
| extensionsettings | 13.0.4 | Enabled | GPLv3+ |
| fax | 14.0.2.4 | Enabled | GPLv3+ |
| faxpro | 14.0.1.5 | Enabled | Commercial |
| featurecodeadmin | 13.0.6.4 | Enabled | GPLv3+ |
| findmefollow | 14.0.1.18 | Enabled | GPLv3+ |
| firewall | 13.0.56 | Enabled | AGPLv3+ |
| framework | 14.0.3.18 | Enabled | GPLv2+ |
| fw_langpacks | 14.0.1 | Enabled | GPLv3+ |
| hotelwakeup | 14.0.1.4 | Enabled | GPLv2 |
| iaxsettings | 14.0.1.4 | Enabled | AGPLv3 |
| infoservices | 13.0.1.3 | Enabled | GPLv2+ |
| irc | | Not Installed (Locally available) | GPLv3+ |
| ivr | 14.0.1.3 | Enabled | GPLv3+ |
| languages | 14.0.1.2 | Enabled | GPLv3+ |
| logfiles | 13.0.10.4 | Enabled | GPLv3+ |
| manager | 13.0.2.5 | Enabled | GPLv2+ |
| miscapps | 13.0.3.1 | Enabled | GPLv3+ |
| miscdests | 13.0.5 | Enabled | GPLv3+ |
| music | 13.0.22.3 | Enabled | GPLv3+ |
| outroutemsg | 13.0.2.1 | Enabled | GPLv3+ |
| paging | 14.0.4 | Enabled | GPLv3+ |
| pagingpro | 14.0.2.9 | Enabled | Commercial |
| parking | 13.0.19.8 | Enabled | GPLv3+ |
| parkpro | 14.0.2 | Enabled | Commercial |
| pbdirectory | | Not Installed (Locally available) | GPLv3+ |
| phonebook | | Not Installed (Locally available) | GPLv3+ |
| phpinfo | 13.0.2 | Enabled | GPLv2+ |
| pinsets | 13.0.8 | Enabled | GPLv3+ |
| pinsetspro | 13.0.9.10 | Enabled | Commercial |
| pm2 | 13.0.5 | Enabled | AGPLv3+ |
| pms | | Not Installed (Locally available) | Commercial |
| presencestate | 14.0.1.5 | Enabled | GPLv3+ |
| printextensions | 13.0.3.1 | Enabled | GPLv3+ |
| queueprio | 13.0.2 | Enabled | GPLv3+ |
| queues | 14.0.2.17 | Enabled | GPLv2+ |
| recording_report | 14.0.1.6 | Enabled | Commercial |
| recordings | 13.0.30.12 | Enabled | GPLv3+ |
| restapi | 13.0.21.1 | Enabled | AGPLv3 |
| restapps | 13.0.92.5 | Enabled | Commercial |
| ringgroups | 14.0.1.4 | Enabled | GPLv3+ |
| setcid | 13.0.6.2 | Enabled | GPLv3+ |
| sipsettings | 14.0.27.2 | Enabled | AGPLv3+ |
| sms | 14.0.4.5 | Enabled | Commercial |
| soundlang | 14.0.4.5 | Enabled | GPLv3+ |
| speeddial | | Not Installed (Locally available) | GPLv3+ |
| superfecta | | Not Installed (Locally available) | GPLv2+ |
| sysadmin | 14.0.14 | Enabled | Commercial |
| timeconditions | 14.0.2.13 | Enabled | GPLv3+ |
| tts | 13.0.10 | Enabled | GPLv3+ |
| ttsengines | 13.0.7.3 | Enabled | AGPLv3 |
| ucp | 14.0.2.9 | Enabled | AGPLv3+ |
| userman | 14.0.3.44 | Enabled | AGPLv3+ |
| versionupgrade | | Not Installed (Locally available) | Commercial |
| vmnotify | 14.0.1.1 | Enabled | Commercial |
| voicemail | 14.0.1.26 | Enabled | GPLv3+ |
| voicemail_report | 13.0.13.3 | Enabled | Commercial |
| weakpasswords | 13.0.2 | Enabled | GPLv3+ |
| webrtc | 14.0.3.7 | Enabled | GPLv3+ |
| xmpp | | Not Installed (Locally available) | AGPLv3 |
| zulu | 14.0.4.6 | Enabled | Commercial |
+---------------------+------------+-----------------------------------+------------+
We used bulk handler on this server to convert from Chan_SIP to PJSIP. Things seemed fine without load but once we got to 20 or above calls call quality started to drop fast. Chanspy went to shit, voicemail was bad, announcements/IVR were bad.
When we got to our normal load of around 50 calls during the day the main asterisk thread was around 200% nonstop and it kept getting to 30 constant load average. Chanspy was useless, voicemail was unusable due to most everything skipping, and IVRâs/Announcements were an abomination. Call quality was so bad the phones were near unusable.
Essentially PJSIP couldnât handle it. Long story short we had to split the server and it seems that PJSIP starts having issues around the 400-500 mark under these conditions. We had to switch the server back to chan_sip and then do a full restore to get it working normally again.
Unrelated to that issue but happening at the same time we also found out that Polycoms can cause an infinite number of hint registrations that eventually crash asterisk.
A customer had *85XXXX (Pickup parked call prefix) as a BLF on their Polycom 550âs. It registered 27,000 times to a single park.
P.S. I canât find the full ticket/info on this one quickly.
Also unrelated setting voicemail MWI subscription type to AUTO with Yealinks results in voicemail flickering on and off randomly, think it does it with busier servers as it works best when the server isnât very active. Iâve had to set it to Unsolicited however it seems thereâs a ticket in asterisk claiming that doing that can cause core dumps (we had them) on PJSIP.
I believe what you are saying but it differs significantly from what Digium (Now Sangoma) just presented at Astricon in regards to pjsip performance.
I think you need to look into Home - Asterisk Documentation.
The real issue here is people throwing N-extensions at PJSIP and treating it like chan_sip. You have to spend the time to get this to work. Throwing a lot at it and saying ârevert revertâ doesnât help anyone. Where are the logs? Whereâs the backtrace? Unfortunately youâve already reverted.
I understand you have a business to run but you have to understand it from a the other side as well
What does that mean, in what way can you âtreatâ pjsip differently than chansip?
Treating the configurations as if they are the same. Not specifically in this thread but an example is saying âit works fine with chan sipâ. Ok. Did you modify any settings of the extension? Or did you just use the defaults and when you had issues you reverted. Iâm.not specifically saying this thread. Iâm commenting on knee jerk reactions of pjsip doesnât work so I just went to chan sip and Iâm done. Sorry canât get you logs because I have other stuff to do. Then when a thread like this comes around you have people saying donât use pjsip because they had errors or misconfigurations they never attempted to troubleshoot. Again not necessarily this thread
But anyways. This thread was asking âshould I use pjsip or sipâ. The ending of this thread is âdonât use pjsip because it didnât work for me yesterdayâ with no logs of any kind itâs sort of aggravating.
Keep using what works for you however Chan_sip is getting deprecated this year. So keep that in mind. Iâd rather people use pjsip so we can fix issues.
Additionally if youâd have seen the performance stats of pjsip youâd want to use it over chan sip.
Agreed. I like pjsip, and it works for me most of the times. I have problem with national telco IMS which sends DID in tel uri format. It makes FreePBX pjsip unusable in that case. I have to switch to chan_sip or use Yeastar whose PBX is patched to support tel uri on pjsip.
Well if yeastar patched it then why are they not submitting it back to asterisk since that is what open source is all about.
I would not know. It sure would be nice if they do.
I really prefer using FreePBX cause it is better and more customizable.
Is PJSIP not a replacement for Chan_SIP? I know there are some setting changes, which is expected, but shouldnât it be able to handle about the same load as Chan_SIP?
We spent more than enough days trying to figure out the problem. We found various minor issues and mitigated or fixed them but the main issue was something relating to PJSIP core that we cannot change.
This is why I did not make a ticket. We were dealing with a disaster and did not have the resources to spend creating tickets and getting diagnostic data, could not wait for it to be fixed. At this point the logs have been over written and its too late for any live debugging data.
I do programming as well so I understand you need logs to debug the problem but we cannot revert back just to get diagnostic data but there is some major bug. One symptom of the bug is messed up voicemail quality along with all recorded messages having choppy or horrible quality under load.
Well without logs you are providing nothing for us to even help diagonse if you have a issue or not. Guess we will see if anyone else ever complains. We have tens of thousands of systems on PJSIP with no reports of this. So letâs not keep going back and forth here with you stating things but not giving us any data. If yoi truly battled it for days but you never thought to get logs and open a ticket early on. Just seems all odd.
I am closing this thread as itâs going side ways. If someone can replicate this please open a ticket with us.
Howdy,
What Yeastar model and what firmware are you using?
We use Yeastar S series PBX, all models share same firmware. They introduced tel uri support in 30.6.0.3. All versions after that support tel uri.