Indeed, I am probably being unfair in giving the short shrift to the existing dedication to SEMS that is valiantly upheld by a few members of the community, between Juha and Sipwise. I didn't mean to do that.
Having said that, I do not think the questions I have raised about SEMS' continuing viability as a platform dependency are unfounded.
One metric is the Sems mailing list:
Once upon a time, close to a decade ago, it was relatively lively, if only because Stefan Sayer more or less solely answered all questions and addressed all issues. It has been defunct since about 2016, more or less, and as far as I'm aware, the Google Group that was meant to replace it does not actually exist, at least anymore:
Second, to the extent that commit volume or any derivatives thereof attest to the larger picture:
We know, of course, that quantity is not quality, that voluminous commits do not go on indefinitely at the same level even in actively maintained projects, and that this is not the only repo. Still, I think some kind of trend can be deduced here.
Third, the experience of building it does not suggest that someone is actively preoccupied with this.
None of this is anyone's fault, obviously; on the contrary, I salute and deeply appreciate the developers of SEMS for giving us this wonderful work. However, I think it's important to avoid illusions about where the open-source edition is in the lifecycle.
-- Alex
On Dec 30, 2024, at 11:27 am, Henning Westerholt <hw@gilawa.com> wrote:
Hello Ben,
yes, there are different PRs and smaller changes/fixes that gets merged. Juha is doing here some substantial work.
We are having some customers that are using it, and we did some packaging for that. So far (with the SBC module for B2BUA) we did not observe any critical issues we needed to fix.
Cheers,
Henning
From: Ben Kaufman via sr-users <sr-users@lists.kamailio.org>
Sent: Montag, 30. Dezember 2024 16:19
To: sr-users@lists.kamailio.org
Cc: Ben Kaufman <bkaufman@bcmone.com>
Subject: [SR-Users] Re: how to call loose_route() after adding route header without using msg_apply_changes?
... As the latest changes seem to be within the last month.
https://github.com/sems-server/sems
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768
From: Ben Kaufman <bkaufman@bcmone.com>
Sent: Monday, December 30, 2024 9:18 AM
To: sr-users@lists.kamailio.org <sr-users@lists.kamailio.org>
Cc: Alex Balashov <abalashov@evaristesys.com>
Subject: Re: [SR-Users] Re: how to call loose_route() after adding route header without using msg_apply_changes?
Not recommending for or against SEMS, but it does appear to be actively maintained, as the latest
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768
From: Alex Balashov via sr-users <sr-users@lists.kamailio.org>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users@lists.kamailio.org <sr-users@lists.kamailio.org>
Cc: Alex Balashov <abalashov@evaristesys.com>
Subject: [SR-Users] Re: how to call loose_route() after adding route header without using msg_apply_changes?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> On Dec 30, 2024, at 8:04 am, Benoît Panizzon <benoit.panizzon@imp.ch> wrote:
>
> Only issue: We have not found a B2BUA behaving the way we would like.
>
> => Any recommendations are very appreciated <=
>
> There are basically two places we could put a B2BUA.
>
> 1: In front of the kamailio registrar (transparent registrar)
> 2: Between Registrar and our Routing Core
>
> We have been burning through: [Asterisk, Sippy B2BUA, FreeSwitch, OpenSIPS, LibreSBC]
I can appreciate this frustration. A major part of the issue here is that some or all of these systems--I am not equally familiar with all of them--are built on top of B2BUAs architecturally, but are really designed to serve some other purpose (voice application server, PBX system, pre-packaged SBC, etc). The mere fact that a system has a B2BUA under the hood is not, per se, a necessary and sufficient precondition for suitability here.
What you need is a a really generic, signalling-only B2BUA whose sole purposes are:
1) Reoriginate call legs / relay requests;
2) Configure, in a fairly fine-grained way, the transparency or opacity with which messages are passed between these.
We are historically fond of SEMS and its `sbc` module: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsems-server%2Fsems%2Fblob%2Fmaster%2Fdoc%2FReadme.sbc.txt&data=05%7C02%7Cbkaufman%40bcmone.com%7C94ccdc16cf974d74998708dd28d7a052%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638711628802994685%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OO0wd1W8o5%2FPIWEE0cdKYhvdU0XbMB2stt8FHq0YO0c%3D&reserved=0 and I believe Sipwise also maintain a fork of it for use inside their switch product ecology.
However, it is important to recognise that SEMS' community edition hasn't really been actively maintained or developed in a very long time. It is nominally open-source, but in practice serves as the back side of a commercial SBC product and gets very little love besides. It has all the tell-tale signs of bit rot, starting with the fact that it can be a bit challenging to build it on some modern Linux distributions. It's difficult for me to endorse it wholeheartedly in 2025 as a way forward. This is a real shame, because I think its `sbc` module fits your use-case almost like a glove.
On the other hand, if you're just trying to plug a short-term gap, bridge from legacy to next-generation, etc., SEMS does still work, for the moment, despite undergoing entropic decay. It might be viable yet.
It's possible that, with a little programming, Drachtio might fit the mold:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrachtio.org%2Fdocs&data=05%7C02%7Cbkaufman%40bcmone.com%7C94ccdc16cf974d74998708dd28d7a052%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638711628803014005%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AGbkMGnLaqCd5z%2Bn4%2BE0uIsSWwUg8fV5S4ojpRYh01M%3D&reserved=0
However, I have heard from others that Drachtio uses an ancient forked version of the Sofia SIP stack internally, and that there some call forking issues with it. This is mere hearsay; I've not independently verified it.
In terms of what you've tinkered with, you may just have to make some compromises, and accept that you can't get everything you might want. If PRACK/100rel is the only thing that stands in your way, just drop it. It's not very important, and the alternatives are worse.
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesys.com%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7C94ccdc16cf974d74998708dd28d7a052%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638711628803026874%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iPYahhbbHBH%2F1%2FJWSPGuXWXDxPLeNpHTkari4yc%2BY4I%3D&reserved=0
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800