USECALLMANAGER with Freepbx17 and PJSIP (To use BLF and conferencing in Cisco 8841)

FreePBX Endpoints
1

Hello,

I am relatively new to FreePBX and have recently installed FreePBX 17. I’ve successfully set up a Cisco 8841 IP phone to work with the system. Currently, I am looking to enable features such as BLF and Call Conferencing on the Cisco 8841.

During my research, I discovered that patching Asterisk with USECALLMANAGER might meet my requirements. However, I noted that the USECALLMANAGER patch is compatible with Asterisk v20 older and works with chan_sip, which is not available in FreePBX 17.

Could you please advise whether USECALLMANAGER can still be utilized with FreePBX 17, and if so, will it function with chan_pjsip? Additionally, I would appreciate guidance on how to apply the patch, or if there are alternative methods to enable these features on the Cisco 8841 with FreePBX.

Thank you in advance for your assistance.

2

There was a recent long thread at What is the best way to handle a custom-built Asterisk on FreePBX 17? going into this some but the patch itself is no compatible at all with chan_pjsip.

3

chan_pjsip’s design philosophy is radically different from chan_sip. An explanation of why this is, is sort of detailed in this article:

Asterisk: Moving on from chan_sip | No Jitter

“One of the most important decisions made in the development of the new functionality was to design both a channel driver as well as a suite of dynamically loadable modules that comprise a full SIP stack. The channel driver would be a relatively slim module, while each module in the suite would provide a specific piece of functionality. The design structure of this stack is such that functionality can be added, modified, or removed with minimal impact on other modules.”

To put this in perspective, this is actually a very old debate in computer science and in operating system design. For example let’s take FreeBSD. Originally with the early versions of FreeBSD if you wanted to support a particular piece of hardware you had to recompile the kernel and switch on a define that would add support for that device into the kernel. You could also go through the kernel and switch off all the support for hardware you DIDN’T have and recompile the kernel.

The advantage of doing this is the kernel would be very small and fast, with the least memory footprint. This is how Walnut Creek in it’s heyday supported over 2000 (yes that’s two thousand) SIMULTANEOUS ftp client transfers on a single Xeon PC server - a feat that Linux has never been able to duplicate since. The disadvantage was that recompiling the kernel was an advanced undertaking that wasn’t beyond the skills of an administrator but was definitely way beyond the skills of a mere user.

Thus enter Loadable Kernel Modules into FreeBSD. Now, you merely had to boot the kernel with a directive to load a LKM for your hardware and voila - support. It also easily allowed companies that wanted to hide their hardware to distribute object modules only without source. Of course the downside of that was those companies often did not bother maintaining and recompiling their LKM’s for newer OS versions but at least you could use your gadget for a few iterations of the OS.

chan_pjsip is like the LKM approach in FreeBSD. It WOULD have been completely possible to refactor chan_sip into what chan_pjsip is today and that is undoubtedly what would have been done - if the chan_pjsip stack hadn’t already existed. (of course, doing that would have made the USECALLMANGER patch un-applyable) Since it did exist the Asterisk developers made the obvious decision to go that direction. Unfortunately, some of the Asterisk developers are somewhat religious zealots. It wasn’t enough to just add in support for a new channel driver and let people just naturally migrate over to it because it was better. No, to a Zealot, life isn’t good unless you can beat the living sheet out of people and FORCE them into The One True Way. So, cooler headed voices - such as the author of the above article - who said, I quote:

“A new SIP channel driver can exist in parallel to the legacy chan_sip channel driver. This approach would give the Asterisk community more time to test and adopt the new channel driver, while maintaining the existing functionality in chan_sip.”

were snowballed and beaten into the asphalt by the Zealots who ripped chan_sip out of the Asterisk tree when it became apparent that not every last person in the world wasn’t migrating over to chan_pjsip as fast as they wanted them to.

The Zealot’s excuse was “whine whine whine whaaaaaa it’s beyond our (pea) brains to maintain 2 separate channel drivers” completely ignoring the FACT that the moment they tore out chan_sip that one of the Asterisk developers (InterLink1) immediately posted it on github and updated it for Asterisk 21. Apparently he has more Asterisk development cojones in his little finger than all the Zealots put together have in their entire collective bodies - but I digress.

Indeed, one of the actual benefits of discarding chan_sip was in essence it “froze” development on chan_sip. Now, anytime anyone has some new scheme they want to do in SIP they have to figure out how to stuff it into chan_pjsip. So that is, actually, a good thing for efforts like the USECALLMANAGER patch. Because now, there’s no more need to modify the USECALLMANAGER patch. It’s development is over since development on chan_sip is over. As has been pointed out by jcolp, it really needs to be ported to chan_pjsip.

Except, that there is a problem. Unfortunately. There ALWAYS is a problem, we just can’t have nice stuff.

The problem is that the Cisco callmanager phones - which contrary to popular belief are NOT going away anytime soon (or Cisco wouldn’t have written the multiplatform 3PCC firmware) expect ALL modules to be ready and active in Asterisk at all times. I don’t know why this is - whether the phone are constantly polling for status or some such - but the Callmanager Patch developer knows - or at least, he did know at one time, when he wrote the patch. (I assume that’s WHY he selected chan_sip to patch) But for this to work with pjsip would mean ALL modules in chan_pjsip would need to be loaded at startup and remain active in memory at all times. Which if you think about it - sort of completely defeats the purpose of chan_pjsip having loadable modules in the first place. In an optimal Asterisk situation, chan_pjsip would only load whatever modules are needed by the SIP devices that register in and dynamically load and unload them as needed changed on the phones and trunks. I’m NOT an Asterisk designer or expert in chan_pjsip so I don’t know if that is how it actually works - and clearly the author of the USECALLMANAGER patch isn’t either. Possibly chan_pjsip could be cudgeled into submission and load everything and keep it loaded all the time and thus make the Cisco Enterprise phones happy - but I don’t know. And, the CALLMANAGER patch author is apparently not interested in finding out, either.

I am personally working on creating a new patch from USECALLMANAGER that applies to the chan_sip channel driver that Interlink1 made available that applies to Asterisk 21. The problem is that Interlink1 didn’t just take the discarded channel driver and brush it up to apply cleanly to Asterisk 21. Would that it have been so easy!!! Sigh. Instead, he had some other fish to fry - which mainly concern updates to the channel driver that seem to make it more compatible with certain types of SIP trunks - that are incompatible with the USECALLMANAGER patch. However, it should be possible to produce a patch that reverses his updates that are not compatible and add in the USECALLMANAGER patch then produce a patched chan_sip that applies cleanly to Asterisk 21. I’ve been in communication with the author of the USECALLMANAGER patch to do this and he’s interested and helping a bit so we will see how that works out.

But, unfortunately, since Interlink1 made his changes, which are incompatible with the USECALLMANAGER patch, this does mean that the fork of chan_sip is going to bifurcate. I don’t like that since it means more work to maintain for what I personally regard as changes Interlink1 made that really aren’t anywhere near as important as support for the Cisco phones. Interlink1 for sure knew about USECALLMANAGER patch when he created his fork of chan_sip he for sure could have incorporated it if he wanted to. But, like I said, he had other fish to fry.

Ultimately what all this boils down to is a philosophical difference. Cisco has, in fact, already washed their hands of the entire situation and is not interested in refereeing in a Zealot war. They produced the 3PCC firmware which you can buy for not a lot of money, and update your CP8841 to a much more supported phone, there’s even “orficial” documentation for provisioning those phones here:

How to provision Cisco 8800 series 3PCC phones on FreePBX/PBXAct Endpoint Manager (EPM) - FreePBX Community Documentation - Sangoma Documentation (atlassian.net)

And there’s plenty more help here:

Configure SIP Settings on the Cisco IP Phone 8800 Series Multiplatform Phone - Cisco

I also personally have a CP8845 running the 3PCC firmware in my test lab and if all you have is ONE Cisco CP8841 then even I’ll advise you to just grit your teeth and buy the update.

The reality is that with effort you can find used CP8845 videophones for $25 off Fleabay and with an extra $35-$40 for the 3PCC firmware update you have a standards-compliant videophone that will have cost you $65 and will immediately sell on Fleabay for $100, and is equivalent to a brand new videophone costing several hundred dollars. The real use of the USECALLMANAGER patch, in my opinion, is supporting the OLDER phones like the CP8941 videophone which DO NOT have a multiplatform firmware update available from Cisco. There is Enterprise SIP firmware available - but most were loaded with SCCP firmware. While there IS a chan_sccp channel driver that works with those, that’s another story for another time.

1 Like
4

  • Chan_pjsip was introduced in Asterisk v12 in 2013 with the intention of replacing chan_sip as the primary SIP driver in Asterisk.

  • Chan_sip was officially announced as deprecated for Asterisk v17 in 2019 with the intent of full removal in Asterisk v19.

  • Both chan_sip and app_macro had their removal extended Asterisk v21 to allow this project to deal with it.

  • Chan_sip (and app_macro) where removed from Asterisk as of v21 in 2023.

Everyone had 10 years to migrate and move to chan_pjsip. This includes the community, projects and third-party developers using Asterisk. The fact that chan_sip was being replaced and removed was communicated by the Asterisk project continuously over the past decade. The project extended deadlines to accommodate projects like FreePBX.

My question to projects like USERCALLMANAGER or others that haven’t made any attempts to migrate their solutions to chan_pjsip; Why have you sat on your hands for a decade?

5

As well from a developer perspective, modules can have others as dependencies so that means if the call manager patch was implemented as a standalone module (which it probably could be due to the interfaces we provide) it could define the others it depends on and the module loader would just handle it.

6

If Asterisk is ever going to graduate beyond a mere base for others to build on it must be inclusive. Nothing you have said, Tom, discusses the REASON that chan_sip was removed. It is, as I said, over philosophical differences in approaches to how to best code a SIP driver. The Asterisk “fanboys” have used FUD - as you are using here - to try to claim that chan_pjsip is “better” This is rubbish because what is “better” for the devs is not necessarily better for the users. Clearly chan_pjsip was NOT up to the task of whatever Interlink1 needs to do with whatever SIP provider he is using that is non-standard enough to NOT be able to work with chan_pjsip which is why he forked chan_sip and modified it for his own purposes, and which is why I’m attempting to do the same.

Nobody, including me, is arguing that chan_pjsip isn’t easier to code on. The issue is that the Asterisk developers could have simply continued to carry chan_sip in the source tree, and responded to any feature request additions for it with a “sorry but chan_sip is frozen you need to request that feature addition in chan_pjsip” They simply could have kept the flag in the code that by default disabled building it. If, due to bit-rot, one day it failed to build without errors - so what? Leave it in there and if in the future someone else needs it to work they can solve the bit-rot errors like Interlink1 did.

The ONLY thing that ripping it out does is satisfy some OCD person who probably incessantly cleans their house over and over when they aren’t writing code. The USERS only see the compiled binaries obtained by apt-get or rpm which in the default build wouldn’t even include it.

Every last thing I have read posted by ANYONE on this who is anti-chan_sip who isn’t a developer is a variation of a bigoted response including yours. Not a single response - other than the article I posted - makes any argument based on actual coding issues. And clearly the FEW dev’s who have posted on the actual coding issues are wrong or Interlink1 couldn’t have ported chan_sip to the current version of Asterisk.

As I said this is nothing more than a philosophical argument over Open Source religious zealots on which is better - a modular approach or a monolithic approach. I’m a veteran of those wars I saw them all to often with FreeBSD’s infancy. There are advantages to each approach and I will point out that NetBSD and FreeBSD could run on 4GB ram on an 80386 CPU because of a monolithic approach which is very probably less than what is in one of those Cisco phones you hate so much.
And once more I will point out that Cisco washed it’s hands of this nonsense years ago with 3PCC. The fact that EPM doesn’t even support 3PCC phones and you have to start with an antique Linksys SPA508G and modify that in EPM, is utter proof of the sheer bigotry against Cisco that’s being carried out by FreePBX by pretending the 3PCC phone firmware does not exist. Honestly just how difficult would it be to add support for Cisco 78xx and 88xx phones running 3PCC? To a commercial product that Sangoma gets money for?!?!? Talk about cutting off your nose to spite your face, that’s some world-class bigotry there!!!

7

Mainly because it was so old, not 100% RFC compliant and so massive that making any significant changes would have required pretty much tearing it down and starting from scratch. That’s the broad stroke of it, I’m sure a developer from the project could give more insight.

8

I didn’t write the patch nor have I worked on chan_sccp (another victim of bigotry IMHO and BTW it HAS successfully been migrated to Asterisk 21) so I can’t speak for whether or not the interfaces would work with it. Nor am I an advanced enough coder to port the stuff over to a standalone module.

I WILL point out though that the concept of a “channel driver” in Asterisk IS IN FACT an “interface” It’s an interface that is not only exploited by the current chan_sip that Interlink1 produced but by chan_sccp, another not-wanted-here channel driver. What exactly is the point of even writing separate channel drivers at all if the Asterisk gatekeepers throw away ones they don’t like?

When people ask “why don’t the authors of chan_sccp/CALLMANAGER-patch etc. implement them as a module” I will turn that question on it’s head and ask "for the entire existence of the CALLMANAGER patch why didn’t the Asterisk developers incorporate it into chan_sip years and years ago long before chan_sip was “deprecated” That patch shouldn’t exist because it should have been a part of chan_sip the month after the patch was originally created. There are OTHER peculiarities that clearly were incorporated into chan_sip. This one was not, instead it was rejected - because the Asterisk maintainers didn’t want to be inclusive of Cisco phones. And then when Cisco DID capitulate to Asterisk and write 3PCC firmware to be compliant to the Asterisk way of doing things and compliant to chan_pjsip, now the FreePBX devs in charge of EPM don’t want to include those in EPM.

So quit blaming the CALLMANAGER patch author. Clearly, nothing anyone can do, whether it be him, or the chan_sccp devs, or Cisco itself, is going to get Asterisk and FreePBX to quit throwing up roadblocks to these phones. If he HAD written this module you speak of, he very likely thought the interfaces in Asterisk would have been changed to screw it up.

I get it. I hate Cisco’s grasping and greedy ways myself and have ripped them publicly about it many times. And the best way to hurt them is to continue to defy their mandatory “End Of Life” for their older stuff. This phone stuff is small potatoes. I’ve successfully supported and used “Obsolete Cisco gear” to destroy new Cisco gear sales my entire career in IT and helped others to do the same. You hate Cisco and want to hurt them? Hit them where they really care the most - in their pocketbook. Ignoring them and blacklisting their stuff merely makes them stronger and bigger.

9

I didn’t blame anyone? I merely stated that the module loader allows specifying dependencies so if they exist, it will guarantee they are loaded, if that is a perceived blocker.

The chan_sip module provided no interfaces for itself, thus it had to be patched so much. The PJSIP implementation provides interfaces for various parts of itself to be extensible to reduce (or eliminate) the amount of modification required to various parts of it.

10

Definitely off-topic but this thread keeps on taking me to

(dogmas can chase pragmas but don’t get to eat them)

11

Then, as I said, simply call a halt to fixing bugs and adding features and leave it in the source tree with a compile time flag disabling compilation by default.

MANY OSS projects including FreeBSD have done this with zero problems. Sometimes people pick up the part later and brush it up sometimes not. With the number of people still using chan_sip that certainly justified leaving it alone.

12

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.