PJSIP adds at least 10 to 15 hours of extra work to every week. chan_sip worked so well for everything we ever needed to do.
Someone please fix this stupidity called pjsip. I have been building Asterisk servers for over 10 years and I spend over half of every day in Asterisk and I have yet to see ANY advantages to pjsip in anything I do. I am now at 12.5 hours so far today and still need to get simple registration and calling between an Asterisk server and an Algo call box.
How about contributing helpful bug reports to the development project? Or even submitting your own patches?
Open Source code doesnāt write itself, you know.
Or you could feel free to demand your money back.
Hi there
I used to think that pjsip was quite horrible to.
It has an advantage over āsipā though; It has fail-over:
When your internet telephone service provider has redundancy build in to their service, pjsip will use it. A more traditional sip.conf based setup does not.
It took me quite some time to get this to work. Not everything is
documented.
My page on the subject;
And some of the stuff on this page can also be used with pjsip;
Suggestions are welcome.
Regards,
Rob
I have to call BS on that last statement. If you really and truly have been building Asterisk servers for 10 years you would know how easy it is to simply download the currently maintained version of chan_sip and add it into Asterisk before compiling it.
If your idea of ābuilding a serverā involves running a bunch of āapt-getā then you are like the Windows Exhange admin who has never run eseutil. This is amateur hour stuff.
Thereās an entire world of FOSS software out there that āmakeā unlocks for you. You are no longer tied to what someone elseās idea of the āproper wayā to run Asterisk - or any other FOSS program - is. And if you donāt like some aspect of how the Asterisk developers wrote Asterisk - then you can change it.
Chan_sip for all versions of Asterisk after 20 lives here
A forked version of chan_sip for Asterisk 22 that is also maintained and has been customized for Cisco phones is here:
Pick one of them and kwitcherbitchin
2 Likes
However, itās also NOT helped by religious zealots who ādeprecateā Really Useful drivers like chan_sip who have developers wiling to maintain them.
The ONLY reason Asterisk developers removed chan_sip is because of trying to push people like the OP over to pj_sip. It would have been no skin off their noses to merely leave chan_sip in the tree, with the default compilation selection of it switched off. Well, the people they were trying to bully around are screaming about it - and now, they are whining about that? Well, at least YOU are whining about that - I donāt know if you are an Asterisk developer or not - if you are, then man up and take what you have coming to you - if not then take your own medicine about contributing code and become one.
Good thing asterisk is opensource. Get your team of willing chan_sip developers together, fork asterisk, and go back to chan_sip. Like you said: Man up and take what you have coming to you, problem solved. If you guys could get TLS supported on chan_sip while your at it, that would be great.
Iāve been doing asterisk for 5 years, 3 in chan_sip, then migrated to pjsip in the last two years. Learning chan_sip was easier for sure, but pjsip has way more functionality and support. That also means more complexity for pjsip, which is where i think a lot of people get upset.
On Thursday 12 June 2025 at 17:24:46, AustinH via Asterisk Community wrote:
Good thing asterisk is opensource. Get your team of willing chan_sip
developers together, fork asterisk, and go back to chan_sip.
I believe the Debian Asterisk packaging team is looking for volunteers - ths
was certainly the case 2-3 years ago.
I would suggest that returning chan_sip to the Debian package of current
versions of Asterisk (as well as maintaining pjsip, of course - theyāre
entirely compatible with each other provider they listen on different port
numbers) would be a good way to achieve your aims, since the Debian package
makes its way downstream into a lot of derivative distributions, so this is
likely a better way of reaching a wide audience of āend usersā who want
chan_sip but donāt have either the inclination or the skill to build Asterisk,
including chan_sip, from source for themselves, rather than just forking the
Asterisk project and releasing a slightly different version of the source code
for people to build.
Antony.
ā
1960s: Letās build a network which can withstand a nuclear war!
1970s: Hm, that looks good, weāll run it on TCP/IPv4.
1980s: Nice, how about letting everyone join?
1990s: Hey, you can make money out of this!
2000s: Oh, you can lose it, too.
2010s: Alright, letās just plug absolutely everything into it.
2020s: Meh, my lightswitch is now connected to my lamp via China.
Thanks for the info everyone. 
Iāll check out the chan_sip versions that are out there port version 20.
Any other thoughts or ideas to make pjsip easier to use would be great. Keep the replies comingā¦
Whatās the issue with using it? Iām lazy so I use the wizard to build my trunks and endpoints and itās easy to configure.
Perhaps if you actually detailed your issues. Provided some logs and even configs we could help with your issues.
Oooo thatās just what I need - encrypted exchanges on a corporate network that uses real switches not toys, where the only person who can sniff anything is the admin who has access to the switchā¦NOT!
I personally use BOTH pj_sip and chan_sip depending on the need and application. Iām not like you or so many other people out there where every last problem is a nail and the only tool I know how to use is a hammer. Iām NOT the zealot that ONLY uses chan_sip - but you sure are the zealot that only uses pj_sip, it appears. Does that scare you? Seems to scare LOTS of people. Oh My God - someone ACTUALLY using Open Source the way it was DESIGNED to be used - call the police, my bubble world is collapsing!!! Doesnāt that heretic know the Only True Right Way is to use the precompiled binaries from Sangoma like any good Windows oops I mean Linucks user is supposed to use? My GOD he must think he actually DESERVES source access to GPL licensed stuff. Quick, QUICK SHOOT THE MFER before he corrupts the youth!!!
I think they are really close to having it done. But it sure does seem to me to be another religious war but this time over the lack of the build sources Sangoma is using for the Debian packages they have released. Presumably if whomever is releasing Asterisk packages in the current Debian package repository then releases their own build sources, then certain people will go to Sangoma saying ānannyer nannyer nannyer seeeā¦THEY can do it now why canāt you?ā
So much fighting over binaries! Makes me think Iām back in one of the Windows groups. RMS would be turning over in his grave - although he aināt dead yetā¦lol.
Little minor correction here. Thereās no space between PJ and SIP, itās PJSIP. Not a big one but Iām still wondering how people are still spelling it wrong after itās been around for 15+ years.
I only use PJSIP, does that make me a zealot? If so, why should it scare me or anyone else for that matter? What exactly is scaring a lot of people? My buds, Scoobs and Shaggy, are cowards and they are asking.
Are you OK? Are you smelling something like burnt toast?
1 Like
Are you telling people NOT to use chan_sip who would benefit from using it? Thatās the hallmark of a zealot - pushing people to do something that is a lot of extra work for them and gains them nothing just for the sake of ārightnessā
I personally think a lot of people using just plain old Asterisk and posting questions in these forums probably would save themselves a hell of a lot of work if they just used FreePBX instead of trying to hack things together with ASCII config files and vi and Asterisk.
For a brand new install PARTICULARLY a commercial one (an install where the installer is doing it under contract for a customer) it would be the most responsible (IMHO) to use FreePBX - assuming the install is vanilla enough for FreePBX to be able to configure it - and go with the defaults in as much of the cases as possible - which would mean pj_sip. That would be the most widely maintainable result, with the most techs out there able to maintain it. Putting together someoneās PBX on an OpenWRT or raspberry PI using a stripped down custom compiled Asterisk is really the height of irresponsibility, IMHO. You always have to take the ābusā factor into consideration when building something under contract for production use. That is, if you get hit by a bus - unless what you built is EASILY maintainable by someone else and well-documented - itās going to be pitched out the second your cold in the coffin - usually at a lot of expense and trouble for whoever you built it for.
Using just pure Asterisk is really only called for in production if you have complex customized call routing configurations that arenāt handled by a vanilla case - and use of something like a Raspberry Pi or OpenWRT system in production is, IMHO, NEVER called for due to the lack of redundancy in the storage medium. Otherwise, a pure Asterisk setup is for development of Asterisk, or hobby use. Or, as a base of another PBX distribution - but then in that case itās not pure Asterisk.
But getting back to the drivers, the underscore in the drivers are from the source code of the drivers, and the configuration menu of Asterisk which shows if you compile Asterisk.
technically the actual name of chan_sip is just āthe SIP driverā while pj_sip is āPJās SIP driverā I donāt know who PJ is or was, though. When I write it, I use the underscore not as a space separator indicator but because almost always Iām talking about both drivers in the same post and itās easy to get lost if your just throwing āSIPā around.
I donāt see a problem recommending chan_sip for the OP as he said that chan_sip worked with an Algo call box while pj_sip did not. I donāt know what an āAlgo call boxā is, although Google seems to think itās a doorbell of some kind - my experience with those intercoms, doorbells, and other such one-way VoIP devices is non-existent, but Iāve read plenty of people complaining about them not working. Frankly I think the entire concept is ridiculous as you can just get a plain old VoIP telephone set and a wall mount for it far cheaper than one of those doorbell telephones - Get yourself a nice Cisco 8845 videophone factory preloaded with the MPP firmware for $100 and put it in a stainless steel weatherproof box and volia - you have an intercom doorphone for your front door. And as a bonus it doesnāt look like an access device for a penitentiary.
But, thatās just me. If the OP has sunk cost into this Algo thingie, and has working configs for chan_sip, and has wasted 12 hours with pj_sip and not gotten it working - then the correct thing, even for production - is to tell him to use chan_sip. If he gets hit by a bus then a future tech can rip the Algo off the wall and pitch it into a trash and replace it with a doorphone that is compatible with pj_sip.
On Saturday 14 June 2025 at 17:33:01, TedM via Asterisk Community wrote:
I donāt know who PJ is or was, though.
āPJSIP was created by Benny Prijono, me, and in case anyone ask (and some
have), the āPJā abbreviation comes from my surname.ā
Antony.
ā
āThere is no reason for any individual to have a computer in their home.ā
- Ken Olsen, President of Digital Equipment Corporation (DEC, later consumed
by Compaq, later merged with HP)
1 Like
Well, Iām not sure what benefit people are getting from running chan_sip these days. I mean, there is that subset that does benefit from making Cisco UCM features work on phones. I just donāt think that subset is enough for a comparatively subpar SIP driver to stick around in a system that doesnāt need two SIP drivers.
Iām not sure where this āa lot of extra workā is coming from. Is it different, sure but itās not a lot of extra work specially since chan_psjip has the wizard that can do all the work for you. As for gaining them nothing but the sake of ārightnessā, it is clear you are unaware of the vast differences. There are numerous benefits for using chan_pjsip over chan_sip.
We have no idea what the issues actually were, just complaining it didnāt work. Yeah the OP got it to work with chan_sip but that doesnāt mean that the issue wasnāt PEBCAK.
Honestly, at this point Iām pretty convinced that if someone was to make a working UCM patch for chan_pjsipā¦you wonāt be having these conversations.
As has been stated numerous times in the past thatās not likely to ever happen due to the way the Cisco Enterprise firmware works and the way chan_pjsip works. Plus the fact that the original UCM patch was never accepted into the chan_sip source tree when chan_sip was still part of Asterisk, so itās unlikely it would be accepted into chan_pjsip either.
The Cisco enterprise firmware expects all phone modules, voicemail, BLF, message waiting, etc. to be active. chan_pjsip does not do that it dynaloads those modules as needed. Obviously, that could be overridden by a patch but the chan_pjsip author would not disable the dynamic loading since thatās one of the āfeaturesā that is regarded as an āadvanceā
Since the current UCM patch incorporates chan_sip, it is nothing more than a semantic argument now to make the claim āworking UCM patch for chan_pjsipā There is a working UCM patch. Itās not a āworking UCM patch for chan_sipā anymore than itās a āworking patch for chan_anything elseā
I believe you were one of the ones calling for the usecallmanager patch author to release a separate driver for the Cisco Enterprise phones - well, he basically did. Maybe to de-offend your sensibilities he should do a s/sip/cisco/g to rename it chan_cisco
Well considering how much the author has ripped out to make it only usable for UCM. They should.
The UCM patch for version 20 (that also applies to 21) only applied to the chan_sip included in Asterisk 20 and didnāt remove anything from it. The Interlinkd1 chan_sip reversion patch for A21 added the following into chan_sip:
- Support for custom parameters (
SIPAddParameterapplication;SIP_PARAMETERfunction;send_oli,uri_parameters_insteadsip.conf config options). This functionality is now also available inchan_pjsip. - Support for fax control. This functionality has also been available in
chan_pjsip. - Support for Homer (HEP) in
chan_sip. This functionality has also been available inchan_pjsip.
Despite the official claims from both developers to the contrary, I successfully applied the ucm patch to the diverged chan_sip from Interlinkd1.
The current UCM patchās version of chan_sip:
- Removed support for DTLS and WebSocket transports.
- Removed global options
insecure,allowguest,autocreatepeer,compactheaders,notifymime,snom_aoc_enabled,storesipcause,regcontext,regextenonqualify,legacy_option_parsingdiscard_hold_retrieval,disallowed_methods,dumphistory,recordhistory,ignoresdpversion,dynamic_exclude_static,refer_addheadersandoutofcall_message_context. - Removed peer options
callbackexten,regexten,promiscredir,g726nonstandard,encryption_taglenandmwi_from. - Removed DMTF mode INFO. Use either
rfc2833orinband. - Removed support the for
Alsoheader in BYE as this was replaced by the REFER method. - Removed support for the
cpim-pidf-xmlevents and Digium presence elements in dialog-info. - Removed support for
call-completion.
because they are either not supported by Cisco phones, are obsolete or are almost never enabled. I donāt believe this makes it only usable for UCM.
Itās unlikely that the UCM patch developer started with the same diff of Chan_sip off the A21 source tree because that version had to have macros removed and other changes to apply to Asterisk 21 and 22. Itās most likely that he pulled a copy of the Interlinkd1 chan_sip, applied his UCM patch to it per my mod suggestions, then went through the result and removed the stuff he removed that didnāt apply to Cisco phones. That would have been the easiest and quickest way to do it. However, he does not explain what chan_sip version he started with.
Itās my considered option that the UCM developer decided to start distributing his modification of chan_sip with his patch because he did not trust the interlinkd1 developer who forked off chan_sip to keep the chan_sip reversion patch maintained. This is understandable because the interlinkd1 developer was asked by multiple people to include the UCM patch into his chan_sip modifications and not only did he refuse, he put out a statement on his fork of chan_sip claiming it was incompatible with the UCM patch - which was a lie, in fact, a lie I pointed out when I posted that the UCM patch applied to the forked chan_sip.
It seems crystal clear thereās strong historical bias against Cisco UCM. I personally believe that this is because Cisco bought itās way into VoIP by the Lightspeed and Selsius Systems acquisitions, and Selsius had developed SCCP, which Cisco spent a few years pushing, thus creating the SIP/SCCP wars, before Cisco finally abandoned SCCP and signed on to the SIP side - while still refusing to create a phone that used the de-facto, industry-agreed SIP standard for phones, instead creating āEnterprise/UCM SIP firmwareā for their 79xx, 69xx and 89xx phones. This in turn spawned the need for the UCM patch in the first place.
But, all of this is history. If you do a greenfield Cisco PBX today, unless you fight them like hell you are NOT going to be sold a UCM, you will be sold Cisco phones running MPP and Cisco Cloud Calling. And, Cisco is doing with their MPP phones what a LOT of people are doing with their telephony gear - locking it to -their- cloud provider - and making you pay a fee per-phone to unlock the MPP so that it can be used with any other cloud provider or with Asterisk.
Itās only if you know the Cisco product intimately that you would end up with a UCM and new Cisco phones running Enterprise UCM firmware. And nobody that knew the product intimately would do that as they might buy a new UCM but they would immediately load the COP file that contains all of the obsolete phone firmwares, and just buy old Cisco enterprise phones by the truckload.
So I donāt see the point of this bias against Cisco anymore. They are now doing what they should have done in the beginning - producing VoIP phones that are industry standard, that work with Asterisk, and are really no different than Sangoma or Grandstream or anyone else producing VoIP PBXes based on Asterisk.
The only real need of the UCM patch/chan_sip is to support older 79xx, 69xx, 89xx and 99xx Cisco phones that cannot run MPP firmware - and only for BLF and multiple line appearances. Basic extensions - single line, as well as MWI and the voicemail button and directory buttons, all work with chan_pjsip just fine with either the UCM/Enterprise firmware on the phone or MPP firmware on the phone.
The reality here is that the entire chan_sip vs chan_pjsip debate isnāt about whatās best for Asterisk or whether the UCM phones can be supported or not. The post that started this wasnāt about a UCM phone in any case. The reality is this debate is about zealotry. You may PRETEND this is about which is better but thatās NOT why you want chan_sip to be gone. You want it gone because your vision of Asterisk is a zealotās vision.
Iāve been involved in FOSS since before the term was coined. Iāve seen good FOSS projects destroyed by this. FreeBSD for example had a major split between Japanese developers and the rest of the community when they put double byte support in and the maintainers didnāt like how they did it and refused to accept the patches. Eventually they reconciled but there have been other fights resulting in BSD to where we now have 3 forks of it, freebsd, netbsd and openbsd - and development effort being wasted
Similar problems happened with OpenWRT/DD-WRT and FreshTomato/Merlin where these religious wars caused by zealots refusing to work together caused splits that diluted development efforts on the overall bigger picture.
If the UCM patch had been folded into chan_sip a decade or more ago, and the support for custom parameters, fax control and HEP added into chan_sip, and the antique obsolete stuff removed from chan_sip and chan_sip kept in the main Asterisk distro, Asterisk would be much stronger for it - because out of the box, it could support brand new phones like the Cisco MPP stuff as well as older stuff like the UCM phones and this Algo phone the OP was struggling with. The same goes for all the additions that cjnut added into SCCP that were also never accepted into Asterisk so he ended up forking sccp. Then, chan_sccp ultimately suffered when Asterisk was modified sometime in version 18 to where transcoding between sccp phones and sip phones/gateways was broken, so even though chan_sccp was brought up to current code with macro removal and will compile on A22, itās effectively dead.
Keeping all that support in Asterisk would have only made it more compatible and stronger in the market. Instead we are reduced to telling people to replace phones like the Algo, flash update phones like the Cisco MPP, and return gateways like the Grandstream one someone was struggling with a week or so ago here, just because Asterisk is a lesser distro - because zealots have this vision the world needs to conform to Asterisk instead of Asterisk conforming to the world.
Iāve had no issues with Algo devices on PJSIP and I use Grandstreamās constantly as my primary FXS gateways, on PJSIPā¦no issues with those either. I even got Viking paging/speaker devices working on it and those are rather limited in their SIP support since their primary method is multicast paging.
Iām pretty sure you said some other things in your post but it was too long to read. I do believe though you did call me a zealot againā¦