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://github.com/sems-server/sems/blob/master/doc/Readme.sbc.txt 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://drachtio.org/docs
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://evaristesys.com
Tel: +1-706-510-6800