Where is selection of SIP Channel Driver?

In the section:

https://sangomakb.atlassian.net/wiki/spaces/FP/pages/242581508/Using+FreePBX+17+with+chan_sip

it states to back-rev Asterisk to version 20 to turn on chan_sip support in FreePBX 17. When this is done and you run FreePBX 17 there is a section under Advanced Settings for selecting the “SIP Channel Driver” you can set it to pjsip, chan_sip or both.

However,

If you build Asterisk version 21 with chan_sip support, (and yes I mean version 21 not version 20) and then install FreePBX 17 on the system, this option does not seem to appear in Advanced Settings.

If I go into Reports, Asterisk Info I can see chansip in there.

I can go to the Asterisk CLI and issue
*CLI> module load chan_sip.so
and i get the usual:

Loaded chan_sip.so
SIP channel loading…
[2024-08-14 18:22:14] WARNING[6736]: acl.c:1065 ast_find_ourip: Unable to get hostname
[2024-08-14 18:22:14] WARNING[6736]: chan_sip.c:40999 deprecation_notice: chan_sip has no official maintainer and is deprecated. Migration to
[2024-08-14 18:22:14] WARNING[6736]: chan_sip.c:41000 deprecation_notice: chan_pjsip is recommended. See guides at the Asterisk Wiki:
[2024-08-14 18:22:14] WARNING[6736]: chan_sip.c:41001 deprecation_notice: https://wiki.asterisk.org/wiki/display/AST/Migrating+from+chan_sip+to+res_pjsip
[2024-08-14 18:22:14] WARNING[6736]: chan_sip.c:41002 deprecation_notice: https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip

I can do a
*CLI> core show help

and see all the sip commands;

sip callforward {on|off} – Sets/Removes the call forwarding extension for a SIP peer
sip donotdisturb {on|off} – Enables/Disables do not disturb on a SIP peer
sip huntgroup {on|off} – Login to/Logout from Hunt Group for a SIP peer
sip notify – Send a notify packet to a SIP peer
sip prune realtime [peer|all] – Prune cached Realtime users/peers
sip qualify peer – Send an OPTIONS packet to a peer
sip reload – Reload SIP configuration
sip set debug {on|off|ip|peer} – Enable/Disable SIP debugging
sip set history {on|off} – Enable/Disable SIP history
sip show {channels|subscriptions} – List active SIP channels or subscriptions
sip show channelstats – List statistics for active SIP channels
sip show channel – Show detailed SIP channel info
sip show domains – List our local SIP domains
sip show history – Show SIP dialog history
sip show inuse [all] – List all inuse/limits
sip show mwi – Show MWI subscriptions
sip show objects – List all SIP object allocations
sip show peers [like] – List defined SIP peers
sip show peer – Show details on specific SIP peer
sip show registry – List SIP registration status
sip show sched – Present a report on the status of the scheduler queue
sip show settings – Show SIP global settings
sip show tcp – List TCP Connections
sip show users [like] – List defined SIP users
sip show user – Show details on specific SIP user
sip unregister – Unregister (force expiration) a SIP peer from the registry

Is there something I’m missing here? I seem to be in a catch-22, that is, I can’t see the option to load chan_sip if FreePBX thinks it’s Asterisk 21 and then since it’s not loaded I can’t access the configuration screens for adding a chan_sip extension, etc. etc. etc. even though those screens exist in FreePBX 17

Bug perhaps?

Asterisk v 21 has removed chan_sip (and macros) you can not build load or use either, to save confusion, remove any remaining modules in /usr/lib/asterisk/modules/ (or god forbid /usr/lib64)

I believe FreePBX code is also based around version checking, not checking of availability since they follow Asterisk as shipped by the project.

There is an advanced setting called “Force Asterisk Version” which you can set to 20. It will mask the actual asterisk ver and may allow you to use 21 with chan_sip.

Edit - if this doesnt work, i would consider it an engineering issue. This seems like a workable way for the very small minority that need both asterisk 21+ and chan_sip.

2 Likes

Asterisk v21 states on their website:

" We understand that there are those who are not yet willing to part with chan_sip. The patch(es) for it’s removal will be generated as part of the removal process. One of the beautiful things about open source software is that you can fork and maintain for yourself whatever you are able. Other current versions of Asterisk will continue to include chan_sip"

dicko, do you have ANY respect for the Asterisk project’s working to make it possible to include chan_sip by generating patches that allow it to be put back? Even THEY say this is a beautiful thing - don’t you think so?

They did. And the result is here:

I will also point out that Asterisk itself is designed to allow other channel drivers to be included. I don’t think that the channel driver that was written by Sangoma to drive their POTs gateway cards that can be purchased is maintained by the Asterisk project, for example.

And of course, there is also the

and

channel drivers which were also forks of the original chan_skinny driver included in Asterisk at all. The Asterisk project had a chan_skinny which was deprecated years ago and removed. However, once more, the Asterisk project did not “slam the door” on the Skinny protocol channel driver. They coud have, easily, by removing the capability of supporting channel drivers. Of course, that would screw over chan_pjsip. But, no sacrifice is to great to preserve “purity”

The simple FACT is that the Project has written Asterisk to permit other channel drivers to be used. They may not include those drivers and they may not maintain those drivers but they are not running around telling people to not use them or remove those drivers from Asterisk like you are.

dicko, you stated “you can not build, load or use either” which is basically not true since (while you can’t build macros and nobody has forked those, apparently, due to need) you can indeed build and load and use chan_sip.

Getting back to my ORIGINAL question - FreePBX 17 includes all the menus for chan_sip, IF you back-rev Asterisk to version 20 using the change asterisk version command in FreePBX 17. I am merely asking why those aren’t visible when chan_sip is included in Asterisk 21.

Note that FreePBX 17 very likely does not retain any of the code that originally created menus for provisioning things under chan_skinny in the older versions of Asterisk, which is why I am not asking about menus for chan_sccp in FreePBX 17. The chan_sccp project documents manual configuration of phones using SCCP using the sccp.conf file. An example is here:

There is also a 3rd party plugin to FreePBX that allows for creation of chan_sccp extensions (and I believe also creates the phone’s TFTP config files) located here:

If you scroll up, way up past your long ramble, you will see that your question was answered by Josh and Lorne.

1 Like

Thanks, Lorne. That setting appears to have been removed from the Advanced Settings menu in FreePBX 17. At least it is not showing up for me. However, I did install FreePBX using the wiki article

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

which uses the

cd /usr/local/src
wget http://mirror.freepbx.org/modules/packages/freepbx/freepbx-17.0-latest-EDGE.tgz
tar zxvf freepbx-17.0-latest-EDGE.tgz
cd /usr/local/src/freepbx/
./start_asterisk start
./install -n

method instead of the

wget https://github.com/FreePBX/sng_freepbx_debian_install/raw/master/sng_freepbx_debian_install.sh -O /tmp/sng_freepbx_debian_install.sh

bash /tmp/sng_freepbx_debian_install.sh --noasterisk

method. I’m wondering now if the first method is unwise since besides this issue, it also does not install the sangoma repo thus many modules (such as firewall, systemadmin, etc.) are not installable that way. (there’s a way you can get around this by manually adding the repos in then installing the key bits and I tried that but it ended up causing a crash in FreePBX)

Unfortunately the install.sh script seems to be a bit “fugly” as most software installers are. Inside the script for example there’s some quick hacks like in one place it will specify an arch variable in another place just arch=amd64, and so on. Clearly the ./install -n method documented in the wiki is different than what the install.sh --noasterisk does.

I asked about this a few weeks ago in another post but unfortunately I got tossed down a rabbithole on this chan_sip thing and never got an answer. I probably should ask again.

Thanks, bill. You are correct, mea culpa. I guess I just need to accept that dicko is incorrigible. Sigh.

There are a lot of strong opinions around here, and some barbs, too. :slight_smile: here’s my opinion: since you are clearly operating outside the typical sandbox of FreePBX, you will need to take on the adaptations yourself and rely on reading the source code to figure out what to do. And probably make changes to the source (contributing back to the project of course) as well. Asking questions about why FreePBX doesn’t support some custom thing is less productive than just digging in and handling it.

No, it’s there. Some advanced settings are hidden until you toggle one or both of these settings at the top of the page
image

You are not including it in Asterisk 21; you are including it in a forked version of Asterisk.

Excellent point. Unfortunately “PHP and Mysql Apps for Dummies” doesen’t cover PHP 8. LOL

Seriously, though, while I am “kind of” operating outside of the sandbox - in this instance I kind of am sort of straddling the sandbox, one leg in and one leg out. chan_sccp definitely is “outside the sandbox” and while that channel driver is still compilable under Asterisk 21, the FreePBX-looking manager is definitely suffering bitrot - likely it needs to be ported to php 8 to even work at all again. But chan_sip is still “kind of supported, I guess, in a way, sort of” since the management menus still exist in FreePBX 17 even though they have to be coaxed to appear. So I’m more at this stage asking “what is the ‘proper’ way” to kind of sort of get the management menus for chan_sip to appear.

Obviously, even keeping them in FreePBX 17 is a way of gently sending chan_sip out the door - sooner or later, the FreePBX project will drop support for Asterisk 20. Since, as jcolp points out, the FreePBX project follows Asterisk as shipped, and the last Asterisk version shipping that included chan_sip is version 20 - once support for 20 goes, the chan_sip menus will follow.

At that time, the logical thing to do would be to extract that code and create a github repository for a chan_sip manager similar to the chan_sccp manager - if someone is still maintaining chan_sip. Right now Interlinkd1 is. I don’t know if he will continue doing so. Right now, chan_sccp is still being maintained and compiles under Asterisk 21 as well - although I don’t know if that will continue being the case.

My own interest in these 2 efforts is in supporting Cisco phones because chan_sip and the USECALLMANAGER patch. I HAVE been able to get that patch to build under Asterisk 21. I had to make a small change to it - just 2 lines - but it does. (of course it took half a day to figure out what those lines were but that’s beside the point) I still have to test that it even works, though.

Which is a mightly surprise to be sure since Interlinkd1 went out of his way to claim the USECALLMANAGER patch would be a “huge merge conflict” and would not be incorporated in his chan_sip. I did NOT find this to be true AT ALL, at least, not with the latest patch version. I did inform the author of that patch a few days ago. I’ve not seen a response. Possibly he’s digesting this - or, possibly, there is bad blood between interlinkd1 and him and neither wants to help the other.

And of course, there is the elephant, Cisco. A few years ago they were beating the drum like insane people claiming all their customers were dying to give up their UCM’s and go to the cloud in webex calling. Since cloud phone systems have exactly the same problem with the “enterprise” load of Cisco’s callmanager firmware as Asterisk does, Cisco released 3PCC firmware which makes their phones as compatible with Asterisk as any Yealink phone is. So we all thought in Cisco-land well that bye bye Enterprise firmware and the need for callmanger patching or chan_sccp supporting sip or whatever you want was out the door.

Except that on the way to this supposed glorious Cloud future, Cisco discovered - just like Sangoma discovered, and Microsoft discovered, that their customers weren’t as dumb as they thought. Their customers were NOT willing to give up their on-premise phone systems and allow their phones to register into some silly cloud system.

So, Cisco has been quietly retrenching. They were going to EOL the 78xx series of phones - they did not. They are sitll selling brand new versions of those with callmanager firmware on them, they are still selling on-premise phone systems and they are still selling tons and tons of brand new phones by the truckload of many models that are all Enterprise callmanager firmware. It is NOT just Ebay scrapings that need callmanager-compatability in Asterisk it’s brand new phones.

And what people keep missing about Cisco is when they decided to put their Cloud and their on-premise phone systems under “smart-licensing” that is, licensing that requires a mandatory yearly fee - they became vulnerable to attack by everyone else - like Sangoma for example.

I often wonder why it is that so many people here seem ignorant of the dollars. If I am forking over a ton of cash every year just to keep my on-premise Cisco UCM running, then ANY tech with a Sangoma phone system running FreePBX can come walking in and say “I can swap out your UCM this weekend and leave all your Cisco phones alone, and set you up with an on-premise phone system that WILL NOT just stop processing calls and roll over and die just because you forgot to send Cisco AND Broadcom checks this month and they suspended your smartlicense account or your VMWare account” and if the dollars are less - which for sure, they will be - then BANG, there goes that Cisco and that Broadcom/VMWare cash cow account.

All that is needed is that phone system and it having the ability to pick up and run with all of the Cisco phones and their enterprise firmware.

Right now, people can certainly make that sales pitch - but if they do they have to say “you got to pay Cisco for 3PCC upgrade licenses for all your phones” which the costs increase the more phones you got. And it’s NOT a cheap $5 per phone deal. Or they got to say “you have to replace all your phones” which now, not only do you have the cost of the phones, (which is higher than the 3PCC route) you also have the cost of the labor running around and replacing all the phones. So under that scenario - it’s a very hard sell.

I frankly would love it if the author of the usecallmanager patch would port it to chan_pjsip. He says he can’t because chan_pjsip doesen’t work the same way as chan_sip does but I don’t know if that’s true or not. I kind of think it isn’t. It might indeed require chan_pjsip to be modified to work somewhat differently than it does now it might require a major effort to do. I’ve NOT got the experience in SIP and in C coding to do that. I will probably be able, as you say I should, to learn enough php8 to be dangerous enough to figure this stuff out and eventually make some contributions to FreePBX - but ultimately for my purposes of supporting these Cisco phones and their damn enterprise/callmanager firmware, I’m still sort of dependent on the channel drivers supporting that firmware. And, the channel drivers that DO support that firmware were written by the old-fashioned way of painstakingly sniffing and reverse-engineering what the heck Cisco is doing in their callmanager implementation of SIP as well as historical work done with older phones that supported SCCP/Skinny (not just Cisco was making those phones) and how THEY worked and much of the early documentation released by those companies is gone, now. I very much doubt you could sit even an experienced developer now down with nothing but access to a UCM and a couple Cisco enterprise phones and a sniffer and create from scratch a new channel driver for Asterisk that mimicked a UCM without a couple years of work and enormous testing. And there’s no need since we already have the 2 efforts that did it years ago.

I didn’t mean “included in the Asterisk Project” I meant included in asterisk by someone compiling it into asterisk. Sorry for the confusion there.

As for forking, just because you compile in a channel driver does not create a fork of Asterisk. A channel driver is a loadable module (.so file) and you define whether or not it loads in a config file. If I don’t define a load line for it then the Asterisk 21 that I compiled with chan_sip when running is identical to an Asterisk 21 compiled without chan_sip when running.

I realize this is hair-splitting but this is a dev group! :wink:

Thank you! Setting those settings to yes and applying then rebooting then going back into Advanced Settings does indeed make the selection of SIP channel driver option appear in FreePBX, and setting that option and applying does add in the menu items to be able to configure chan_sip.

This information could be added to the using chan_sip with 17 wiki page. Recommend you open a GitHub ticket with the proposed changes.

If that happens it needs to be flagged as for advanced users and made very clear that it is 100% unsupported by Sangoma, FreePBX and Asterisk projects. There should be, by requirement, an author/maintainer for said module that hosts the module on their own (github or website) and that any support, features or bugs be directed to the author/maintainer of the module.

My thought on this is the clean way to do this would be to build a VM of this kind of setup and release it as a KVM+qemu, vmware, AWS, hyperv and virtual box VM images. Instructions to the end users would be to fire up the VM under their preferred Hypervisor, login and change hostnames, passwords, MAC addresses, etc. expand the vm disk if desired, and login and change names, system IDs and get a Deployment ID

Obviously you would distribute instructions on how the VM was created but in my experience with these projects hardly anyone ever bothers to read those much less construct their own distro.

That greatly simplifies support since everyone who wants to use it starts out with the same thing.

The exact same thing could also be done with a completely bone-stock installation of FreePBX on Debian12.

For example I could hand off a hyperV disk image to my Windows sysadmin who knows almost nothing about Linux and really would only want to use putty to SSH in, then copy and paste a few commands out of a textfile into the Linux command prompt, and he could get a FreePBX system up and running successfully. His interaction would be to the GUI interface and the GUI interface is completely agnostic to the application’s operating system, he wouldn’t be afraid of that.

And I am quite sure there’s a LOT of system admins out there who are in the same boat. The previous method of ISO installation for FreePBX 16 was pretty daunting to them, too.

This is the model that a number of software application developers are using and it’s a good one. And keep in mind in the Windows Server world, Microsoft DOES NOT charge for additional licenses for Linux VM’s running under Windows Server Standard you can have as many of those as you want.

This is, in fact, something I would like to do - if it would not end up complicating things for the FreePBX project.

The beauty of all this is, you are free to do all of that. There are quite a few projects out there such as IncrediblePBX and IssabelPBX that build off of FreePBX but add their own stuff to it for their community of users. In fact, IncrediblePBX does exactly what you are suggesting be done. They create images for various virtual systems including WSL and Virtual Box.

There is no benefit to this project maintaining a bunch of VM images for various virtualization platforms in the overall scheme. While I am sure there are those out there that would use this the amount that likely would does not justify the extra resources needed to be used to facilitate, maintain and support.

This gets more into a discussion of how Open Source projects including software get distributed to be honest. Encapsulation is a huge deal these days, projects like Docker, and Microsoft’s UWP Containers and the popularity of virtualization all prove that. Don’t forget that Broadcom felt that VMWare’s virtualization business model was so secure they killed the free ESXi server so that really should tell you loads

The real big issue is TRUST. I can roll up a VM and put it up on github but anyone downloading it is like “who is this dude? Is he going to stick something into the VM that’s going to call back to his mothership and collect my data?” Now, I can put links to my websites, my personal info (my Resume has been online for the last 20 years) and so on and they can dig around on my online history and decide if I’m an honest dude or not - maybe opinionated but I’m not going to gun them - and maybe feel secure.

Trust also exists as an issue even with the FreePBX install distro and with the install script. Yes the install script is open source but it’s also really really big and you have to be an advanced administrator to figure out what it’s doing - and it’s also putting a lot of precompiled binaries on to your Debian12 system. Anyone trying out FreePBX for the first time has to make a conscious decision to trust Debian, trust Sangoma and trust FreePBX, and now, if I package up some VM’s of FreePBX that they can download and boot in 5 minutes instead of spending 4 hours building up a Debian system then downloading and installing FreePBX - which might not even work if they have their firewall set to aggressively so some of the repo servers can’t be contacted - if they want to save all that time for trying it out - they have to now, trust me also. THAT’s why I would think that the FreePBX project would be discussing offering VMs.

So, yeah, it’s not as simple as it seems. Sure “anyone” can roll up a distro. But, would you use a PBX vm from “just anyone”?

If it makes you feel better FreePBX does this already.