30 Dec
2024
30 Dec
'24
noon
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:
https://www.mail-archive.com/sems@lists.iptel.org/info.html
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:
https://groups.google.com/d/forum/sems-users
Second, to the extent that commit volume or any derivatives thereof attest to the larger
picture:
https://github.com/sems-server/sems/graphs/code-frequency
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, before
marrying it, I think it's important to be free of any illusions about where the
open-source edition is in its lifecycle.
-- Alex
On Dec 30, 2024, at 11:27 am, Henning Westerholt
<hw(a)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(a)lists.kamailio.org>
Sent: Montag, 30. Dezember 2024 16:19
To: sr-users(a)lists.kamailio.org
Cc: Ben Kaufman <bkaufman(a)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(a)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(a)bcmone.com>
Sent: Monday, December 30, 2024 9:18 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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.
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
On Dec 30, 2024, at 8:04 am, Benoît Panizzon
<benoit.panizzon(a)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.co…
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.…
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%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!