Kalixor SBC so far

airsay · August 21, 2026, 3:30pm

So I enjoy figuring out solutions like these as part of my toolset when working with prospects. I’ve previously done the same with 2600Hz Platform (previously called Kazoo), Sipwise C5, ivozprovider for multitenant, reseller softswitch solutions, as well as dsiprouter and opensips SBC CE for somewhat “open source” SBC solutions. I see a lot of similarities between Kalixor and dsiprouter.

So first issue I observed installing Kalixor, is failed RTPEngine install. From my ivozprovider lab, I’ve got a lot of experience installing Kamailio and RTPEngine and immediately identified the initial issue as uninstalled Linux headers. Tore down that instance, spun up a new Debian 13 instance and immediately ran

root@localhost#: apt update && apt upgrade -y
root@localhost#: dpkg-reconfigure locales (and set locales to en_US)
root@localhost#: hostnamectl set-hostname kalixor
root@localhost#: timedatectl set-timezone America/New_York

I’m not anywhere in the US but I like to set my timezone to US as that’s where I’ve supported all my VoIP end users. I digress

Logged out and logged back in and ran

root@kalixor#: apt install linux-headers-$(uname -r)

To ensure linux headers was properly installed. Ironed out the issue with that install and then ran the SBC install commands from the blog post.

RTPEngine still failed to install properly:

Loading new ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0 DKMS files…
Building for 6.12.101+deb13-cloud-amd64

Building initial module ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0 for 6.12.101+deb13-cloud-amd64
Sign command: /lib/modules/6.12.101+deb13-cloud-amd64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module(s)…(bad exit status: 2)
Failed command:
make -j4 KERNELRELEASE=6.12.101+deb13-cloud-amd64 -C /lib/modules/6.12.101+deb13-cloud-amd64/build M=/var/lib/dkms/ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0/build RTPENGINE_VERSION=26.1.0.0
+0~mr26.1.0.0

Error! Bad return status for module build on kernel: 6.12.101+deb13-cloud-amd64 (x86_64)
Consult /var/lib/dkms/ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0/build/make.log for more information.
dpkg: error processing package ngcp-rtpengine-kernel-dkms (–configure):
installed ngcp-rtpengine-kernel-dkms package post-installation script subprocess returned error exit status 10
Setting up libunbound8:amd64 (1.22.0-2+deb13u3) …
Setting up libgnutls-dane0t64:amd64 (3.8.9-3+deb13u4) …
Setting up libidn12:amd64 (1.43-1) …
Setting up exim4-config (4.98.2-1+deb13u4) …
Adding system-user for exim (v4)
Setting up libnsl2:amd64 (1.3.0-3+b3) …
Setting up liblockfile1:amd64 (1.17-2) …
Setting up exim4-base (4.98.2-1+deb13u4) …
exim: DB upgrade, deleting hints-db
Created symlink ‘/etc/systemd/system/timers.target.wants/exim4-base.timer’ → ‘/usr/lib/systemd/system/exim4-base.timer’.
exim4-base.service is a disabled or a static unit, not starting it.
dpkg: dependency problems prevent configuration of ngcp-rtpengine:
ngcp-rtpengine depends on ngcp-rtpengine-kernel-dkms (>= 26.1.0.0+0~mr26.1.0.0); however:
Package ngcp-rtpengine-kernel-dkms is not configured yet.

dpkg: error processing package ngcp-rtpengine (–configure):
dependency problems - leaving unconfigured
Setting up exim4-daemon-light (4.98.2-1+deb13u4) …
Created symlink ‘/etc/systemd/system/multi-user.target.wants/exim4.service’ → ‘/usr/lib/systemd/system/exim4.service’.
Setting up bsd-mailx (8.1.2-0.20220412cvs-1.1) …
update-alternatives: using /usr/bin/bsd-mailx to provide /usr/bin/mailx (mailx) in auto mode
Processing triggers for man-db (2.13.1-1) …
Processing triggers for libc-bin (2.41-12+deb13u3) …
Errors were encountered while processing:
ngcp-rtpengine-kernel-dkms
ngcp-rtpengine
Error: Sub-process /usr/bin/dpkg returned an error code (1)

with the following output:

9-/var/lib/dkms/ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0/build/nft_rtpengine.c:44:2: warning: #warning “Kernel without CONFIG_BTREE - kernel media player unavailable” [-Wcpp]
10- 44 | #warning “Kernel without CONFIG_BTREE - kernel media player unavailable”
11- | ^~~~~~~
12:/var/lib/dkms/ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0/build/nft_rtpengine.c:7423:10: error: ‘const struct nft_expr_ops’ has no member named ‘reduce’
13- 7423 | .reduce = NFT_REDUCE_READONLY,
14- | ^~~~~~
15:/var/lib/dkms/ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0/build/nft_rtpengine.c:7423:35: error: ‘NFT_REDUCE_READONLY’ undeclared here (not in a function); did you mean ‘MNT_LOCK_READONLY’?
16- 7423 | .reduce = NFT_REDUCE_READONLY,
17- | ^~~~~~~~~~~~~~~~~~~
18- | MNT_LOCK_READONLY
19:/var/lib/dkms/ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0/build/nft_rtpengine.c:7435:10: error: ‘const struct nft_expr_ops’ has no member named ‘reduce’
20- 7435 | .reduce = NFT_REDUCE_READONLY,
21- | ^~~~~~
22:/var/lib/dkms/ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0/build/nft_rtpengine.c:7447:10: error: ‘const struct nft_expr_ops’ has no member named ‘reduce’
23- 7447 | .reduce = NFT_REDUCE_READONLY,
24- | ^~~~~~
25-make[2]: *** [/usr/src/linux-headers-6.12.101+deb13-common/scripts/Makefile.build:234: /var/lib/dkms/ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0/build/nft_rtpengine.o] Error 1
26-make[1]: *** [/usr/src/linux-headers-6.12.101+deb13-common/Makefile:1992: /var/lib/dkms/ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0/build] Error 2
27-make: *** [/usr/src/linux-headers-6.12.101+deb13-common/Makefile:236: __sub-make] Error 2

=== KERNEL ===
Linux kalixor 6.12.101+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.101-1 (2026-08-05) x86_64 GNU/Linux

=== HEADERS ===
ii linux-headers-6.12.101+deb13-cloud-amd64 6.12.101-1 amd64 Header files for Linux 6.12.101+deb13-cloud-amd64
ii linux-headers-6.12.101+deb13-common 6.12.101-1 all Common header files for Linux 6.12.101+deb13
ii linux-headers-cloud-amd64 6.12.101-1 amd64 Header files for Linux cloud-amd64 configuration (meta-package)

=== BUILD LINK ===
lrwxrwxrwx 1 root root 53 Aug 5 14:19 /lib/modules/6.12.101+deb13-cloud-amd64/build → ../../../src/linux-headers-6.12.101+deb13-cloud-amd64

=== DKMS ===
ngcp-rtpengine/26.1.0.0+0~mr26.1.0.0: added

Turns out that RTPengine 26.1.0.0 contains a compatibility bug with Linux 6.12.101+.

Sipwise seems to have fixed that issue in RTPEngine mr26.1.1.10 as shown in this commit: MT#55283 update test for .reduce method · sipwise/rtpengine@d58d637 · GitHub

The SoftswitchOne repository is still publishing the unfixed 26.1.0.0 package, so I had to patch that package locally at:

/usr/src/ngcp-rtpengine-26.1.0.0+0~mr26.1.0.0/nft_rtpengine.c

There were three sections with:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,17,0)
.reduce = NFT_REDUCE_READONLY,
#endif

which I replaced with:

#ifdef NFT_REDUCE_READONLY
.reduce = NFT_REDUCE_READONLY,
#endif

Then ran

dpkg --configure ngcp-rtpengine-kernel-dkms
dpkg --configure -a
apt -f install

So in the end, the version of RTPEngine in the repo needs to be updated to prevent this issue from recurring.

maynor · August 21, 2026, 3:32pm

Hello,

Thank you for reporting this issue and for your feedback.

We will run internal tests to identify and fix the problem and improve our installation scripts accordingly.

Best regards,

airsay · August 21, 2026, 3:39pm

Also wasn’t able to generate certificates using the inbuilt lets encrypt. Had to manually create certs using acme.sh and add as custom cert

maynor · August 21, 2026, 3:42pm

Could you please share a screenshot or the log messages you received when you tried to generate the certificates?

airsay · August 21, 2026, 3:58pm

I don’t have that now, but it asked me to add an _acme-challenge TXT entry which I did. And verified that it was up using CLI tools. When I click on the appropriate button on Kalixor, it always didn’t find the updated _acme-challenge and generated a new one. I’m spinning up a new instance again later today and would probably document that.

While I have you, can you explain the functionality of SIP Accounts under Routing>SIP Trunking>SIP Accounts

I have a dobain created and set to Local Subscriber Table as shown

I also have a SIP Account created and assigned to that domain;

When I try to register, I get a 403 Not Relaying.

I am trying to register directly to the SBC and test inbound and outbound calls to test two-way audio with the “patched” RTPEngine

admin · August 21, 2026, 6:05pm

Hi,

Thank you very much for taking the time to share such a detailed, precise, and high-quality technical breakdown. Your diagnosis is spot on.

You are completely right: the RTPEngine 26.1.0.0 build published in our repository still had the legacy version check (#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,17,0)) for .reduce = NFT_REDUCE_READONLY in nft_rtpengine.c. Under Debian 13 (Trixie) with Linux Kernel 6.12+, Netfilter modified the expression ops interface, causing the DKMS module compilation to fail on fresh installs.

Your local patch using #ifdef NFT_REDUCE_READONLY is identical to the upstream fix Sipwise introduced in commit d58d637 / release mr26.1.1.10+.

We will update the RTPEngine build and publish the updated packages (ngcp-rtpengine-daemon, ngcp-rtpengine-kernel-dkms, and dependencies) in our next upcoming release so it compiles the DKMS kernel module (xt_RTPENGINE) smoothly against Debian 13 (6.12+) kernel headers out of the box.

We really appreciate your feedback and expertise—please let us know if you run into anything else or have any feedback as you continue testing Kalixor!

Best regards,
The Kalixor / Ring2All Team

admin · August 21, 2026, 6:10pm

Hi,

Thank you for reporting this. We traced the issue down to a process-tracking bug in our Let’s Encrypt background handler (which caused it to lose the active challenge session upon confirmation) along with an ACME webroot path mismatch in Nginx for HTTP-01.

Your workaround of generating certs via acme.sh and adding them as a Custom Certificate is completely valid and supported in the meantime.

We have already implemented the fix in our codebase, and the built-in Let’s Encrypt module will be fully resolved in the upcoming release coming out very soon.

Thanks again for your valuable feedback!

airsay · August 21, 2026, 6:42pm

Honestly surprised my post is getting all the way to the top!

I still need to do some testing with actual endpoint PBXs to test registration to the PBXs through Kalixor as well as inbound/outbound calling.

I asked a question earlier about SIP Accounts and directly registering to Kalixor. I’m looking to test inbound and outbound calls using my Trunk and DID.