What is the best way to handle a custom-built Asterisk on FreePBX 17?

So I did the following:

Installed Debian
Installed FPBX 17 per instructions
ran the asterisk-version-switch command and selected Asterisk 20
ran FreePBX and enabled chan_sip in the settings

Then I downloaded and built asterisk-20.8.1.tar.gz with patches

running dpkg-l shows a bunch of asterisk20 binaries installed
apt-get remove asterisk20, asterisk20-core seems to work
make install in the downloaded asterisk-20.8.1 source folder seems to work and seems to
overwrite the binaries that were installed

So, would the “clean” way to do this to be
dpkg-l
apt-get remove everything with an asterisk20-*
make install on your patched asterisk?

Or would the “clean” way to be run asterisk-version-switch, switch it to asterisk 20, then
do a make install on the source of asterisk 20 and just overwrite everything? Since it seems
that maybe that is what is happening?

Could we possibly have a “feature request” for the asterisk-version-switch command that would select “private asterisk version” and then uninstall ALL asterisk versions and set the flag in the FreePBX updater that makes it ignore Asterisk? Then you are responsible for building and running make install on your own Asterisk version?

I also note that the beta is running asterisk 20.8.1 as a downgrade option but the Asterisk team has released 20.9.1, will the asterisk-version-switch command be updated for that?

Also, why does asterisk21-core still list as an installed package, (just core) and is
asterisk-sounds-core-xxxxxxxx 1.5-2.sng12 also overwritten by a make install?

Basically, I want to order the car with a Ford 350 Cleveland then yank the heads, port them, and reinstall without the car/FreePBX thinking anything has changed.

While it is unlikely this will be a thing as it seems like what they may call a “you problem” you can put in a feature request GitHub - FreePBX/issue-tracker: The unified FreePBX issue tracker.

Want a clean custom install?

apt purge asterisk*
apt install git
mkdir -p /usr/src
cd /usr/src
git clone https://github.com/asterisk/asterisk 
cd asterisk
contrib/scripts/install_prereq install
./configure --help # make some custom choices
./configure --. . . .
make menuselect # make your custom choices

If you get stuck at any step , then its time to get and read some FM’s.

Kickstart, @billsimon has some older recipes in the wiki

May be you can install the asterisk first manually and then use install script to install the freepbx17 with “–noasterisk” option.

I also note that the beta is running asterisk 20.8.1 as a downgrade option but the Asterisk team has released 20.9.1, will the asterisk-version-switch command be updated for that?

thanks for reporting this, we will check this.

Additionally, we are updating the Asterisk release process to automatically create Github issues in the FreePBX issue tracker upon release so that FreePBX is automatically notified, and to allow people to monitor those issues if they wish.

1 Like

What are the choices selected by the default FreeBSD 17 install when it installs Asterisk in the install script? Is there a document anywhere for that?

Yeah, this is NOT the way to do it, dicko.

Here’s what I get:

apt purge asterisk* (bunches of stuff deleted)
cd /usr/src/asterisk-20.8.1
make install (output is Asterisk has been successfully installed)

root@FreePBX17-Beta:/usr/src/asterisk-20.8.1# asterisk-version-switch
bash: /usr/local/sbin/asterisk-version-switch: No such file or directory

root@FreePBX17-Beta:/usr/src/asterisk-20.8.1# dpkg -l | grep freepbx
ii freepbx17 17.1-1.sng12 amd64 Asterisk FreePBX Web Interface
root@FreePBX17-Beta:/usr/src/asterisk-20.8.1#

However what is missing is asterisk-freepbx and some other packages that the Freepbx17 install puts in there and that show in dpkg -l

I think I’ll try the asterisk manual install first and then the script with the -noasterisk option. Fortunately blowing away and recreating the system is as simple as powering it down, copying over the qcow2 file and powering it back up.

It might not be YOUR way, but I have used that method for donkeys years successfully.

You need to read the FM’s about git to get the branch you want to base your customization on first

git branch -r

Asterisk is NOT dependent on FreePBX, it is the other way around. When you have an Asterisk you like you can then install FreePBX, for every version of FreePBX I suggest you first run

./install --help

bookworm no longer has asterisk packages in it’s own repos, you will need to install third-party sources to get any asterisk deb pkgs , version 17 script will do that but then you won’t have a custom built asterisk

Kgupta,

The noasterisk option requires TWO --'s not 1 -

I’ll scotch it again and start over. Sigh.

Yes but it’s a hack, dicko. Meatball surgery. That

apt purge asterisk*

command destroys commands like

asterisk-version-switch

and I’m sure many others. I’ll do what I can to follow the “orficial” guide at

https://sangomakb.atlassian.net/wiki/spaces/FP/pages/10682545/How+to+Install+FreePBX+17+on+Debian+12+with+Asterisk+20

That “hammer” is how asterisk-version-switch works… it is in package naming… he missed 2 characters “asterisk21”

root@pbx:~#
asterisk-sounds-extra-en-alaw/bookworm,bookworm,now 1.5-2.sng12 all [installed]
asterisk-sounds-extra-en-ulaw/bookworm,bookworm,now 1.5-2.sng12 all [installed]
asterisk-sounds-extra-en-wideband/bookworm,bookworm,now 1.5-2.sng12 all [installed]
asterisk-sounds-moh-opsound-alaw/bookworm,bookworm,now 2.03-1.sng12 all [installed]
asterisk-sounds-moh-opsound-sln/bookworm,bookworm,now 2.03-1.sng12 all [installed]
asterisk-sounds-moh-opsound-ulaw/bookworm,bookworm,now 2.03-1.sng12 all [installed]
asterisk-sounds-moh-opsound-wideband/bookworm,bookworm,now 2.03-1.sng12 all [installed]
asterisk-version-switch/bookworm,bookworm,now 6.1-26.sng12 all [installed,upgradable to: 6.1-27.sng12]
asterisk21-addons-bluetooth/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-addons-core/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-addons-mysql/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-addons-ooh323/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-addons/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-core/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-curl/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-dahdi/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-doc/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-flite/bookworm,now 2.4-26.2505af1.sng12 amd64 [installed,upgradable to: 2.4-37.2505af1.sng12]
asterisk21-g729/bookworm,now 2002-9.sng12 amd64 [installed,upgradable to: 2003-1.sng12]
asterisk21-odbc/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-ogg/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-res-digium-phone/bookworm,now 3.6.8-1.sng12 amd64 [installed]
asterisk21-resample/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-snmp/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-speex/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-sqlite3/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21-voicemail/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]
asterisk21.0-freepbx-asterisk-modules/bookworm,now 1.0-1.sng12 amd64 [installed]
asterisk21/bookworm,now 21.0.2-1.sng12 amd64 [installed,upgradable to: 21.3.1-1.sng12]

Why would you want to switch away from a custom built asterisk you just so laboriously built ?

--noasterisk will show in ./setup --help 

@kgupta did post -- the forum reformatted it to look like one, copy and pasting blindly can get you into all sorts of trouble

I can’t offer any assistance on installing the custom Asterisk, but I’m very curious about the requirement. I assume that you have a trunking provider or a remote PBX of another brand, which was incompatible with Asterisk, so you modified chan_sip to allow Asterisk to interoperate. If so, can you provide details? This enhancement might be useful to enough others and worthwhile to incorporate into the master (though I assume it would be redone for pjsip).

Cisco callmanager patch, of course. What else? Cisco is the single largest source of cheap used desk phones on Ebay. I myself have 80 (eighty) CP 6921’s boxed and ready to be handed over to anyone in the city who wants to show up and hand me 2 $100 bills. They can certainly then spend the next couple months shipping them out by 3s and 4’s and make beer money.

Unfortunately, it’s impossible to port the callmanager patch to pjsip because the way that ALL Cisco Enterprise phones are designed, the phones must have a constant connection to the SIP server in order for BLF to work properly. According to the patch author, chan_sip is a monolithic driver that does this, pjsip is not.

The Asterisk managers were not unaware that their decision to remove this driver was not going to be loved. They put hooks into the current code to allow it to be put back in - and the driver itself was forked and available here:

GitHub - InterLinked1/chan_sip: Maintained version of the original chan_sip Asterisk SIP channel driver

So it is quite possible to build chan_sip into Asterisk 21 Unfortunately, as stated by the person who forked chan_sip in the readme page:

To-Do List

  • The usecallmanager patches are not currently incorporated here because they present a huge merge conflict.

In other words - the author of the usecallmanager patch is free to patch the fork and most likely that will be incorporated - but the author is (apparently) not interested in doing the merge work, at least he was not when I last emailed him

A phone is a phone is a phone is a phone. 12 number keys, a hold button, various hangup and such and you got an equivalent to a brand new desk phone costing $100 or more per instrument. And in any site that has a UCM in service - the phones are already placed.

Incidentally, I have also not been able to get pjsip to work with Cisco routers setup with POTS voice cards as voice gateways while chan_sip does. I don’t know why this is.

pjsip works just fine with Cisco phones if you are willing to give up BLF. So for basic phones - like the 6921’s - those can make calls no problem and you probably don’t need BLF

Cisco changed licensing on the UCM a few years ago and now Broadcom is in on the act - running an on-prem UCM these days is VERY expensive and on top of that - it’s completely a subscription project. Cisco BADLY wants people to ditch their on-prem UCMs and go to the webex calling cloud but that’s even more expensive.

So most people with UCM’s and significant phone deployments are sitting on their UCM’s and riding them out as long as possible.

It is also possible once the phones are flashed with multiplatform firmware to use them with most cloud providers (clearyip, ring central, and most likley sangoma’s own cloud offering) since the phone basically works like an antique Linksys SPA. Cisco did use an early version of Asterisk for the 3PCC firmware testing. And of course, if the phones are flashed, then they could be used with pjsip.

At current Ebay prices you can get used Cisco 8845 videophones in the $30 range - even adding in Cisco’s fee for converting the enterprise versions of those phones over to MPP firmware - that’s still cheaper than buying a brand new desk videophone.

So I think we are going to see Cisco enterprise firmware phones around the market for many many more years.

Because if something goes wrong I want to be able to determine if the bug is FreePBX or Asterisk. All of this is beta testing in the lab and may never see production. In addition, production may require a supported system from Sangoma. The problem there is Sangoma does not list compatibility for modern Cisco Multiplatform firmware aka 3PCC firmware, they don’t support those phones in EPM. But I assume they won’t support chan_sip either.

That might be necessary for you, but not what the OP was asking, I was replying to the OP, why are you insisting on hijacking this thread?

Again, for 15 years or more, I have been deploying FreePBX on Debian, and every one could be considered a ‘custom’ build, many of those boxen started on Debian 6 or 7 are ticking over with FreePBX as debian ‘rolls over’ every year or two, further none have ever relied on a third party repo. hence the apt purge thingy, Never needed a commercial module, and suggest you should move your bitches and whines to the ‘Distro’ forum, this one is for ‘Development’

I don’t know what this means exactly, but from a “connection” perspective they both work the same way if configured to do so.

Well, I guess technically not the same if you include DNS as our PJSIP implementation actually implements the RFC for doing SRV/NAPTR including failover and load balancing which chan_sip does not but that would not apply to a phone.

Could you take the modified chan_sip and repackage it as chan_cisco? The phones are not changing and it wouldn’t be used for trunks, so once accepted, it should require little maintenance.

That’s an interesting idea, since the production environment (debian 12) is static it should be quite easy to build a custom .deb file that installs the driver. Of course, it would require Asterisk 20. Most likely if I did that I’d name it chan_cisco_sip though.

My eventual goal of course is to prod the author of the callmanager patch to merge his patch into the maintained version of chan_sip for Asterisk 21. That probably won’t happen if the de-facto path for running these phones under FreePBX is to downgrade Asterisk to version 20. I keep wondering just how difficult doing the merge myself would be and if I could pull it off.

There’s an enhanced chan_sccp out there which has also been patched for Asterisk 21 intended to be used with the Cisco 69xx series of phones running the Cisco “Enterprise skinny” firmware which is reputed to be “better” than running the Cisco “Enterprise sip” firmware. Supposedly, chan_sccp also works with the Cisco sip firmware but I have not messed with that yet. That could be packaged as chan_cisco_sccp.

Unfortunately, the author of the patch, here:

Deprecated functions in Asterisk v21 ¡ Issue #609 ¡ chan-sccp/chan-sccp ¡ GitHub

states that it’s a hack and probably not the right way to do it, but it works for him. Another big obstacle with dealing with these older model x9xx phones running sccp is Cisco has “cleaned house” and removed all sccp and sip phone firmware from it’s website. While I’m not afraid of making the older firmware available for download (and neither is 3CX since they are hosting it publicly also) as Cisco seems to be ignoring the fact that it’s out there, the other issue is provisioning. The “old” way of doing it was to run the 3rd party provisioner module under FreePBX, which has fallen into disuse and bad bitrot since EPM and I don’t believe runs under FPBX 17 or the newer Debian, as it requires antique php code. I personally have no issue provisioning phones with the Unix editor “vi” at the command line, but others do.

Lastly, the worst problem (and the reason I replaced all of the sccp phones in my enterprise) is that when you have a mixed environment of SCCP and SIP phones, every extension-to-extension phone call has to be transcoded in the PBX. It was worse with the sccp videophone calls to the sip videophone calls since not only is the PBX transcoding the audio it’s converting the video on the fly as well. And this was on a Cisco-brand UCM. With those calls the video was NOT smooth at all, very choppy.

I can see a site that has maybe 500 Cisco 8941 sccp videophones in service, keeping everything sccp even though Cisco’s constantly threatening people that they are going to remove SCCP support in their UCM “one of these days” (although as of yet they have not done so even in their latest UCM) But if you have a mixed plant of SIP and SCCP phones, you really need to switch every phone over to SIP. I could have done that by reflashing our older phones but I elected to just buy newer model phones. And what helped a lot was Cisco deciding to EOL the 88xx videophones and NOT eoling the 78xx non-videophones (even though the 8845 is by far and away a superior phone to the 78xx series) which is causing prices on the used market for the superior phone to crash.

So really there are 3 possible packages here:

chan_sip for Asterisk 21, no support for Cisco BLF phones, just used for complete backwards compatibility with a phone or a gateway or something that just refuses to work with pjsip (such as a Cisco router running 12.x advancedip firmware that almost certainly does not implement SRV)

chan_cisco_sccp for Asterisk 21 BLF support for Cisco x9xx model (sccp) phones possibly Cisco Enterprise SIP phones

chan_cisco_sip for Asterisk 20 BLF support for Cisco x8xx model (sip) phones

The “supported” way going forward with all this mess would be to get FreePBX to add support for the 3PCC Cisco phones into EPM and use those phones with pjsip. That would put pressure on customers with large Cisco phone deployments to just bite the bullet and upgrade their phones from the Enterprise firmware to the Multiplatform 3PCC firmware. I’d be happy to donate a 7841 running 3PCC if there was any interest in adding support for these into EPM.

How do these just not work with pjsip? SIP is SIP. So knowing what is refusing to work would help determine what the issues might be.

Also, why would the router implement SRV? It’s just a DNS lookup and the phones would need to be what supports SRV so it prefixes the record lookup properly to be resolved.