I would be remiss if I didn’t mention that FreeSWITCH is a very decent b2bua; especially light-weight if you are already proxying media on rtpengine and “bypass media” in freeswitch.
Example: https://github.com/fredposner/cluecon2023 Regards, Fred Posner > On Dec 30, 2024, at 10:18 AM, Ben Kaufman via sr-users > <[email protected]> wrote: > > Not recommending for or against SEMS, but it does appear to be actively > maintained, as the latest > > > Kaufman > Senior Voice Engineer > > > > E: [email protected] > > > > > 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 <[email protected]> > Sent: Monday, December 30, 2024 7:37 AM > To: [email protected] <[email protected]> > Cc: Alex Balashov <[email protected]> > 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 <[email protected]> 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 -- > [email protected] > To unsubscribe send an email to [email protected] > Important: keep the mailing list in the recipients, do not reply only to the > sender! > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions -- > [email protected] > To unsubscribe send an email to [email protected] > Important: keep the mailing list in the recipients, do not reply only to the > sender! __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected] To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender!
