I’m going to tag @csalameh I hope you don’t mind, Charles.
I have a feature request for FreePBX. As you know Asterisk 22 dropped chan_sip and so if FreePBX detects Asterisk 22 it removes all of the parts of it’s interface that allow you to configure chan_sip.
You have probably heard of the “usecallmanager” patch for Asterisk. This applies to chan_sip in Asterisk. It allows full feature use of Cisco phones running Enterprise code.
There has been speculation on what the developer of the usecallmanager patch should do. Suggestions have been for him to port it to chan_pjsip he has stated that would be very difficult due to the way chan_pjsip is implemented.
Another suggestion was that he create a new driver named something like chan_cisco or some such.
Well, that’s basically what he did in February - he took the chan_sip code and combined chan_sip into his patch so that now, his patch when run against Asterisk 22, restores chan_sip and his modifications for Cisco phones.
What I would like is if FreePBX could modify the logic that checks for the version of Asterisk and disables the chan_sip interface if the version is above 20, so that it instead checks for chan_sip and if chan_sip is loaded then it does not disable the chan_sip interface in FreePBX.
Normally before sticking a feature request into a Github repo I like to run it by the community for their judgement. If people say “oh that’s stupid nobody would use that” or “that’s already covered by XYZ” then it just adds noise to the github repo and there’s no point in adding it.
If OTOH I don’t get that kind of response - then I sorta like to dig into the code myself and see if it’s a trivial patch that can be made - and at least, if I can provide pseudo-code or an actual working patch, I’d prefer to do that.
In this case, since neither of you have knocked it - I’ll conclude that it’s worthy of consideration. (I understand that actual kudos for a feature request idea isn’t something I’ll ever get on this forum, LOL) So now it’s my responsibility to at least try to see if I can make the patch myself.
I chatted with Mike White and Nenad and they will get back to you with what they can do Ted. I am not the expert in this field but appreciate the tag and will see what I can do. I just wanted to acknowledge receipt.
There’s really not much to do. You just need to modify the check to allow Asterisk version > 20 to allow chan_sip to be shown if the chan_sip module exists.
The only real question to answer is: What is the actual demand for this? I can’t imagine it being very high. Since this is a minor change, then lack of demand may not really matter.
I would say that the caveat of this is, if it does get added there should be no support for it from Sangoma. This is 100% a 3rd party add-on that will require the maintainer of the chan_sip package to provide support for when things do not work right. If this 3rd party modified channel driver causes problems, Sangoma is in no way obligated to resolve them.
I can’t rule out there wouldn’t be. But that would be a result of a manual process not the built in asterisk-switch-version that exists. Even then, you still need to expose the chan_sip stuff in Advanced Settings to use it. This check would be just allow that option to be exposed.
Again, all this would/should do is allow chan_sip to appear in the available drivers list and expose the chan_sip pages in the GUI.
Once you patch any version of Asterisk with the usercallmanager patch, you’ve relegated your support avenue to the maintainer of said patch. But since this isn’t just patching chan_sip but re-adding code that was completely removed from Asterisk v21+, support is going to be null as well. This would apply to an modified version of chan_sip being added back into Asterisk as well.
I, personally, would reject this feature add. It just leads to too many problems down the road and the use of chan_sip, in any form, on 21 or higher shouldn’t be supported.
Yeah, your just “if it doesen’t help ME then screw it” attitude isn’t helping.
People like you tell people like the patch programmer “your not gonna crap up our beeeautiful Asterisk with your nasty patch” and refuse to accept it into upstream.
Then a decade later you throw out the thing that he was wanting to patch.
Then he’s like “how do I add this functionality” and you and yours are like “we make it modular. Go and write a modular plug in and then we will let you play in our sandbox”
So he does it. And presents it to you - and your thinking to yourself “dammit, he actually did what we told him - how am I gonna blow him off now?”
Just be honest. You hate this patch and it’s NEVER going to be good enough. Excuse after excuse. We can’t add it because it’s nasty and it needs to be modularized. Now we can’t support the module you wrote after doing what we told you to do because honestly we are just assholes who don’t want your contribution but we will just make up some baloney about it being minimal and so why do it since it’s unimportant and tell you that to your face.
So riddle me this - how exactly do you think ANY OTHER developer out there who is maybe THINKING of writing a module YOU WANT is doing to view your dissing this effort? I’ll tell you. They are gonna think if the Asterisk community is so snobby that they won’t even lift a finger to help this guy who’s been trying to support Cisco phones for over a decade EVEN TO THE POINT he went and did what they told him to do - make a module - and now they are complaining about something else - then screw them. Why should I put my effort into making another module for Asterisk to have a bunch of snobs cold-shoulder it?
Fortunately, I think the rest of the community doesn’t have this snobby attitude and make whiny comments like “what’s the demand for this”
Pump your brakes. I was the first to tell you to put this in the issue tracker. My opinion that this shouldn’t be added, is that my opinion. I even said this was such a minor change that doing it wasn’t a really big deal.
However, in regards to the support. What I said stands. You can’t get support from the Asterisk team on any v20 if you modified the chan_sip driver by a third party. The maintainer of that patch must be the one to support that patch.
If you are going to add chan_sip in to v21 or future versions, you are doing that on your own. Whoever is maintaining that version of chan_sip is the one that needs to support it. Sangoma should not support it at all (and the Asterisk team won’t).
The usercallmanager has always made chan_sip non-supported by Asterisk/Sangoma. This would be no different.
of FreePBX installations how many are using Cisco enterprise phones?
of those how many are choosing to use the Cisco firmware vs the MPP which was specifically designed to work with non-Cisco PBX?
of that number how much interest is there in the features of the usecallmanager patch?
I think “doing the numbers” is the right approach; my estimate is that the number who would benefit is extremely small but I haven’t done the numbers so I don’t know.
Thanks! I will say this about this issue - Asterisk developers and many community members have said Asterisk was designed to be modular - and it’s architecture allows for plug ins. FreePBX is the same way - it’s architected to have many plugins - some commercial some free. And, a project can’t have it’s cake and eat it too - it can’t design the project to be modular then be inimical to modules that don’t conform to some vision of the project.
Asterisk and FreePBX isn’t the first FOSS project that has faced additions that the original developers never expected. How it deals with them is really important.
I don’t use SCCP myself. But, I went to the trouble of writing a compilation/installation guide for the old chan_sccp driver, and posting it here, a number of months ago, just to show that it’s still possible to use - to be inclusive, as it were.
The proper way to get support from the Asterisk team is to BUY PBXact, in my opinion. Everything else is just people not willing to put their money where their mouths are.
bill this is a flexible number that has these variables:
how easy is it to use Cisco phones with FreePBX?
How many of those phones are entering the secondary market (the 69xx, 89xx, 79xx series are no longer being manufactured and the 88xx just went EOL)
How many of the currently produced Cisco phones (with 3PCC firmware) are being bought for use with “3rd party systems” (keep in mind this patch is not needed for 3PCC phones)
You might even ask, how many new installs are even buying desk phones vs running softphone software on a PC
I don’t pretend to know those numbers. I can observe trends and as I’ve said in the past - the trends I’ve seen indicate that users really DON’T like the softphone approach, and that there’s still TONS of deskphones being sold even though the telephony industry seems hell bent on believing the desk phone is an anachronism and the new thing is the softphone.
I will say that I’m still seeing posts about Cisco deskphones in this forum. The things seem unwilling to die…