Aye, Freeswitch is great. But it doesn't offer very fine-grained control over what's passed; it still has a somewhat orthogonal purpose.
> On Dec 30, 2024, at 10:39 am, Fred Posner via sr-users > <[email protected]> wrote: > > 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! -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com 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!
