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
[img]<https://www.sip.us/>
[
img]<https://www.siptrunk.com/>
[
img]<https://www.flowroute.com/>
________________________________
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.
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!