... As the latest changes seem to be within the last month. https://github.com/sems-server/sems
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 [img]<https://www.sip.us/> [img]<https://www.siptrunk.com/> [img]<https://www.flowroute.com/> ________________________________ From: Ben Kaufman <[email protected]> Sent: Monday, December 30, 2024 9:18 AM To: [email protected] <[email protected]> Cc: Alex Balashov <[email protected]> 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: [email protected] 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 <[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<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://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<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://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<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!
__________________________________________________________ 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!
