Hi List
To handle CPE which can only handle a limited number of route header (PacketCable SIP specification), I need to store and restore the route header (limited topology hiding only affecting Route Header) to present the CPE only one Route or RR header.
I pass the ID of the stored route-set via RR param.
So when I get a message back from the CPE is:
* Take ID from RR param and pull stored route set from cache. * remove_hf("Route"); * insert_hf("Route: $avp(stored-routeset)\r\n"); * msg_apply_changes(); * loose_route();
I found loose_route() only to be able to correctly determine the next hop, if I first did apply the changes.
But after adding rtpengine to the mix, I got back into the known situation that calling rtpengine (on the branch route) after calling msg_apply_changes() results in duplicate SDP.
Is there a way to get loose_route() to operate on freshly added header without calling msg_apply_changes?
Hi Benoît,
What about the PacketCable spec constrains you only to a single Route header? I have never heard of such a constraint, and if it existed, it would be a pretty damning violation of a mechanism very deeply infused into the heart of RFC 3261.
I mean this with all due respect: once again, you're doing something very clever, but maybe a little too clever, perhaps so clever that you're the only Kamailio implementor on the planet who is doing it. When that happens, it is possible that 1) you and you alone have such unique problems, and must devise correspondingly intrepid and ingenious solutions, or 2) there is another (simpler) approach. I would encourage you to think more strategically and less tactically in these cases: perhaps it is programmatically possible, somehow, to solve the problem, but does it mean that it should be solved that way, or solved at all?
I cannot say what the better approach is in this case, but it's safe to say that no proxy should be storing and restoring the Route set. If you truly have a type of endpoint that does not implement the most basic elements of the SIP standard, perhaps a business decision should be taken to simply not support it?
-- Alex
On Dec 27, 2024, at 5:18 am, Benoît Panizzon via sr-users sr-users@lists.kamailio.org wrote:
Hi List
To handle CPE which can only handle a limited number of route header (PacketCable SIP specification), I need to store and restore the route header (limited topology hiding only affecting Route Header) to present the CPE only one Route or RR header.
I pass the ID of the stored route-set via RR param.
So when I get a message back from the CPE is:
- Take ID from RR param and pull stored route set from cache.
- remove_hf("Route");
- insert_hf("Route: $avp(stored-routeset)\r\n");
- msg_apply_changes();
- loose_route();
I found loose_route() only to be able to correctly determine the next hop, if I first did apply the changes.
But after adding rtpengine to the mix, I got back into the known situation that calling rtpengine (on the branch route) after calling msg_apply_changes() results in duplicate SDP.
Is there a way to get loose_route() to operate on freshly added header without calling msg_apply_changes?
-- Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Is there a way to get loose_route() to operate on freshly added header
without calling msg_apply_changes?
I doubt it. My experience with kamailio tells me that this simply is never going to work.
I've two suggestions (three if we count agreeing with Alex's suggestion to consider not supporting that UA). - Get kamailio to manually do the steps that loose_route() would do anyway. This is messy, because it requires good understanding of loose routing. You might remove the supplied Route header field, then get the transport/host/port from your saved Record-Route header fields, and then set the $du and $fs explicitly (and then get any _other_ Record-Route values and insert them as Route values), all while being aware of "r2" parameters (to know whether to exclude one or two Route values). It might work, but I don't think I'd ever want to even attempt this nonsense. - Add TOPOS to kamailio. That strips the topology from the message, and then the faulty UA should never see Route or Record-Route header fields so never wreck them. It requires kamailio to keep state in a database, though, but it should work well.
James
On Fri, 27 Dec 2024 at 12:19, Alex Balashov via sr-users sr-users@lists.kamailio.org wrote:
Hi Benoît,
What about the PacketCable spec constrains you only to a single Route header? I have never heard of such a constraint, and if it existed, it would be a pretty damning violation of a mechanism very deeply infused into the heart of RFC 3261.
I mean this with all due respect: once again, you're doing something very clever, but maybe a little too clever, perhaps so clever that you're the only Kamailio implementor on the planet who is doing it. When that happens, it is possible that 1) you and you alone have such unique problems, and must devise correspondingly intrepid and ingenious solutions, or 2) there is another (simpler) approach. I would encourage you to think more strategically and less tactically in these cases: perhaps it is programmatically possible, somehow, to solve the problem, but does it mean that it should be solved that way, or solved at all?
I cannot say what the better approach is in this case, but it's safe to say that no proxy should be storing and restoring the Route set. If you truly have a type of endpoint that does not implement the most basic elements of the SIP standard, perhaps a business decision should be taken to simply not support it?
-- Alex
On Dec 27, 2024, at 5:18 am, Benoît Panizzon via sr-users sr-users@lists.kamailio.org wrote:
Hi List
To handle CPE which can only handle a limited number of route header (PacketCable SIP specification), I need to store and restore the route header (limited topology hiding only affecting Route Header) to present the CPE only one Route or RR header.
I pass the ID of the stored route-set via RR param.
So when I get a message back from the CPE is:
- Take ID from RR param and pull stored route set from cache.
- remove_hf("Route");
- insert_hf("Route: $avp(stored-routeset)\r\n");
- msg_apply_changes();
- loose_route();
I found loose_route() only to be able to correctly determine the next hop, if I first did apply the changes.
But after adding rtpengine to the mix, I got back into the known situation that calling rtpengine (on the branch route) after calling msg_apply_changes() results in duplicate SDP.
Is there a way to get loose_route() to operate on freshly added header without calling msg_apply_changes?
-- Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Good advice.
However, this is such an incredibly bizarre, weird thing to do, that I think one should do some due diligence and really get down to the bone of why exactly you see the need to do this.
A noncompliant UA might be a surface-level story. Perhaps there is some other casual factor. I'd get to the bottom of it. The most important thing of all is to not respond with the hammer of Kamailio programmatic route script flexibility just because you see some kind of nail; maybe it's not meant to be nailed.
In every major theology, there are things which are "haram" or similar -- things which are clearly possible, but which are against God's will.
-- Alex
On Dec 28, 2024, at 12:02 pm, James Browne james@frideo.com wrote:
Is there a way to get loose_route() to operate on freshly added header
without calling msg_apply_changes?
I doubt it. My experience with kamailio tells me that this simply is never going to work.
I've two suggestions (three if we count agreeing with Alex's suggestion to consider not supporting that UA).
- Get kamailio to manually do the steps that loose_route() would do
anyway. This is messy, because it requires good understanding of loose routing. You might remove the supplied Route header field, then get the transport/host/port from your saved Record-Route header fields, and then set the $du and $fs explicitly (and then get any _other_ Record-Route values and insert them as Route values), all while being aware of "r2" parameters (to know whether to exclude one or two Route values). It might work, but I don't think I'd ever want to even attempt this nonsense.
- Add TOPOS to kamailio. That strips the topology from the message,
and then the faulty UA should never see Route or Record-Route header fields so never wreck them. It requires kamailio to keep state in a database, though, but it should work well.
James
On Fri, 27 Dec 2024 at 12:19, Alex Balashov via sr-users sr-users@lists.kamailio.org wrote:
Hi Benoît,
What about the PacketCable spec constrains you only to a single Route header? I have never heard of such a constraint, and if it existed, it would be a pretty damning violation of a mechanism very deeply infused into the heart of RFC 3261.
I mean this with all due respect: once again, you're doing something very clever, but maybe a little too clever, perhaps so clever that you're the only Kamailio implementor on the planet who is doing it. When that happens, it is possible that 1) you and you alone have such unique problems, and must devise correspondingly intrepid and ingenious solutions, or 2) there is another (simpler) approach. I would encourage you to think more strategically and less tactically in these cases: perhaps it is programmatically possible, somehow, to solve the problem, but does it mean that it should be solved that way, or solved at all?
I cannot say what the better approach is in this case, but it's safe to say that no proxy should be storing and restoring the Route set. If you truly have a type of endpoint that does not implement the most basic elements of the SIP standard, perhaps a business decision should be taken to simply not support it?
-- Alex
On Dec 27, 2024, at 5:18 am, Benoît Panizzon via sr-users sr-users@lists.kamailio.org wrote:
Hi List
To handle CPE which can only handle a limited number of route header (PacketCable SIP specification), I need to store and restore the route header (limited topology hiding only affecting Route Header) to present the CPE only one Route or RR header.
I pass the ID of the stored route-set via RR param.
So when I get a message back from the CPE is:
- Take ID from RR param and pull stored route set from cache.
- remove_hf("Route");
- insert_hf("Route: $avp(stored-routeset)\r\n");
- msg_apply_changes();
- loose_route();
I found loose_route() only to be able to correctly determine the next hop, if I first did apply the changes.
But after adding rtpengine to the mix, I got back into the known situation that calling rtpengine (on the branch route) after calling msg_apply_changes() results in duplicate SDP.
Is there a way to get loose_route() to operate on freshly added header without calling msg_apply_changes?
-- Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hi James
I've two suggestions (three if we count agreeing with Alex's suggestion to consider not supporting that UA).
Unfortunately, at the moment, not an option.
- Get kamailio to manually do the steps that loose_route() would do
anyway. This is messy, because it requires good understanding of loose routing. You might remove the supplied Route header field, then get the transport/host/port from your saved Record-Route header fields, and then set the $du and $fs explicitly (and then get any _other_ Record-Route values and insert them as Route values), all while being aware of "r2" parameters (to know whether to exclude one or two Route values). It might work, but I don't think I'd ever want to even attempt this nonsense.
I started working in this direction and got this working for transport UDP. After that, I noticed that not msg_apply_changes() caused the issue, but that by mistake I was indeed calling rtpengine_manage() twice in some re-invite situations which caused the duplicate SDP.
- Add TOPOS to kamailio. That strips the topology from the message,
and then the faulty UA should never see Route or Record-Route header fields so never wreck them. It requires kamailio to keep state in a database, though, but it should work well.
I found TOPOS not being able to cope with spiralling calls in this situation which is very common:
* Two customer, Alice and Bob, registered on the same Kamailio Registrar running TOPOS. * Kamailio Registrar are not dialog aware and do not route calls. For this there is a central 'core' kamailio instance running dialog, gathering CDR and knowing how to route calls.
So the call flow is:
Alice => Registrar => Core => Registrar => Bob
The same call passes the registrar twice. This, as I observe (it's still possible I did something wrong), breaks topos and header get replaced the wrong way!
Hello Benoit,
let's focus on the topos topic then and try to solve it. This should then help in this scenario a lot. I just wrote you another e-mail about it.
Cheers,
Henning
-----Original Message----- From: Benoît Panizzon via sr-users sr-users@lists.kamailio.org Sent: Montag, 30. Dezember 2024 08:39 To: James Browne via sr-users sr-users@lists.kamailio.org Cc: Benoît Panizzon benoit.panizzon@imp.ch Subject: [SR-Users] Re: how to call loose_route() after adding route header without using msg_apply_changes?
Hi James
I've two suggestions (three if we count agreeing with Alex's suggestion to consider not supporting that UA).
Unfortunately, at the moment, not an option.
- Get kamailio to manually do the steps that loose_route() would do
anyway. This is messy, because it requires good understanding of loose routing. You might remove the supplied Route header field, then get the transport/host/port from your saved Record-Route header fields, and then set the $du and $fs explicitly (and then get any _other_ Record-Route values and insert them as Route values), all while being aware of "r2" parameters (to know whether to exclude one or two Route values). It might work, but I don't think I'd ever want to even attempt this nonsense.
I started working in this direction and got this working for transport UDP. After that, I noticed that not msg_apply_changes() caused the issue, but that by mistake I was indeed calling rtpengine_manage() twice in some re-invite situations which caused the duplicate SDP.
- Add TOPOS to kamailio. That strips the topology from the message,
and then the faulty UA should never see Route or Record-Route header fields so never wreck them. It requires kamailio to keep state in a database, though, but it should work well.
I found TOPOS not being able to cope with spiralling calls in this situation which is very common:
- Two customer, Alice and Bob, registered on the same Kamailio Registrar
running TOPOS.
- Kamailio Registrar are not dialog aware and do not route calls. For this there is a central 'core' kamailio instance running dialog, gathering CDR and knowing how to route calls.
So the call flow is:
Alice => Registrar => Core => Registrar => Bob
The same call passes the registrar twice. This, as I observe (it's still possible I did something wrong), breaks topos and header get replaced the wrong way!
-- Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr- users@lists.kamailio.org To unsubscribe send an email to sr-users- leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 30, 2024, at 2:39 am, Benoît Panizzon via sr-users sr-users@lists.kamailio.org wrote:
So the call flow is:
Alice => Registrar => Core => Registrar => Bob
The same call passes the registrar twice. This, as I observe (it's still possible I did something wrong), breaks topos and header get replaced the wrong way!
As far as I know, this situation badly cries out for a lightweight B2BUA. It's no accident that pretty much all SBCs are based on a B2BUA.
However, I could be mistaken...
-- Alex
Hi Alex
As far as I know, this situation badly cries out for a lightweight B2BUA. It's no accident that pretty much all SBCs are based on a B2BUA.
However, I could be mistaken...
You are absolutely right!
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 (can not route registrations, very little control over failure handling, wants to handle RTP)
* Sippy B2BUA (After some attempt in implement missing features like routing of OPTIONS messages, we just gave up)
* FreeSwitch (Looked very promising, but failed by not correctly handling / dropping packets as duplicates that are not duplicate in 100rel required situations with same rseq from parallel forked calls/different totag)
* OpenSIPS (Failed in almost same scenario as FreeSwitch, I believe the issue was that all replies with different totag were mapped to the same totag on the first leg, causing the origin to drop packets as duplicate)
* LibreSBC (After contact with development team, learned that their scope is interconnections, not serving as SBC for CPE access)
Dropping 100rel and PRACK support might have solved the issue with FreeSwitch and OpenSIPS, but this is something which I would prefer not to do.
On Dec 30, 2024, at 8:04 am, Benoît Panizzon benoit.panizzon@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:
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
Not recommending for or against SEMS, but it does appear to be actively maintained, as the latest
Kaufman Senior Voice Engineer
E: bkaufman@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@lists.kamailio.org Sent: Monday, December 30, 2024 7:37 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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.com...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.o...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%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
... As the latest changes seem to be within the last month.
https://github.com/sems-server/sems
Kaufman Senior Voice Engineer
E: bkaufman@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: Ben Kaufman bkaufman@bcmone.com Sent: Monday, December 30, 2024 9:18 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@evaristesys.com 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: bkaufman@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@lists.kamailio.org Sent: Monday, December 30, 2024 7:37 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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.com...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.o...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%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Yeah, it's true, there are occasional commits. Perhaps I was a little zealous in my characterisation of it as "unmaintained". Can I bargain you down to "there's not a lot of energy around the project"?
On Dec 30, 2024, at 10:19 am, Ben Kaufman bkaufman@bcmone.com wrote:
P {margin-top:0;margin-bottom:0;} ... As the latest changes seem to be within the last month.
https://github.com/sems-server/sems
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768
From: Ben Kaufman bkaufman@bcmone.com Sent: Monday, December 30, 2024 9:18 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@evaristesys.com Subject: Re: [SR-Users] Re: how to call loose_route() after adding route header without using msg_apply_changes? <!-- p {margin-top:0; margin-bottom:0} --> Not recommending for or against SEMS, but it does appear to be actively maintained, as the latest
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
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 sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 7:37 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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:
Reoriginate call legs / relay requests;
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... 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.o...
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%2Fevaristesy... Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hahaha Yeah, I don't know how much love it actually gets, but I've seen others on the list get defensive of it, and figured I'd try to prement 🙂
Kaufman Senior Voice Engineer
E: bkaufman@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@lists.kamailio.org Sent: Monday, December 30, 2024 9:20 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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.
Yeah, it's true, there are occasional commits. Perhaps I was a little zealous in my characterisation of it as "unmaintained". Can I bargain you down to "there's not a lot of energy around the project"?
On Dec 30, 2024, at 10:19 am, Ben Kaufman bkaufman@bcmone.com wrote:
P {margin-top:0;margin-bottom:0;} ... As the latest changes seem to be within the last month.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...https://github.com/sems-server/sems
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768
From: Ben Kaufman bkaufman@bcmone.com Sent: Monday, December 30, 2024 9:18 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@evaristesys.com Subject: Re: [SR-Users] Re: how to call loose_route() after adding route header without using msg_apply_changes? <!-- p {margin-top:0; margin-bottom:0} --> Not recommending for or against SEMS, but it does appear to be actively maintained, as the latest
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
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 sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 7:37 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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:
Reoriginate call legs / relay requests;
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...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.o...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%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hello Ben,
yes, there are different PRs and smaller changes/fixes that gets merged. Juha is doing here some substantial work.
We are having some customers that are using it, and we did some packaging for that. So far (with the SBC module for B2BUA) we did not observe any critical issues we needed to fix.
Cheers,
Henning
From: Ben Kaufman via sr-users sr-users@lists.kamailio.org Sent: Montag, 30. Dezember 2024 16:19 To: sr-users@lists.kamailio.org Cc: Ben Kaufman bkaufman@bcmone.com Subject: [SR-Users] Re: how to call loose_route() after adding route header without using msg_apply_changes?
... As the latest changes seem to be within the last month.
https://github.com/sems-server/sems
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.commailto:bkaufman@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: Ben Kaufman <bkaufman@bcmone.commailto:bkaufman@bcmone.com> Sent: Monday, December 30, 2024 9:18 AM To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alex Balashov <abalashov@evaristesys.commailto:abalashov@evaristesys.com> 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: bkaufman@bcmone.commailto:bkaufman@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@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Sent: Monday, December 30, 2024 7:37 AM To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alex Balashov <abalashov@evaristesys.commailto:abalashov@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@imp.chmailto:benoit.panizzon@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.com...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.o...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%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Indeed, I am probably being unfair in giving the short shrift to the existing dedication to SEMS that is valiantly upheld by a few members of the community, between Juha and Sipwise. I didn't mean to do that.
Having said that, I do not think the questions I have raised about SEMS' continuing viability as a platform dependency are unfounded.
One metric is the Sems mailing list:
https://www.mail-archive.com/sems@lists.iptel.org/info.html%EF%BF%BC
Once upon a time, close to a decade ago, it was relatively lively, if only because Stefan Sayer more or less solely answered all questions and addressed all issues. It has been defunct since about 2016, more or less, and as far as I'm aware, the Google Group that was meant to replace it does not actually exist, at least anymore:
https://groups.google.com/d/forum/sems-users%EF%BF%BC
Second, to the extent that commit volume or any derivatives thereof attest to the larger picture:

We know, of course, that quantity is not quality, that voluminous commits do not go on indefinitely at the same level even in actively maintained projects, and that this is not the only repo. Still, I think some kind of trend can be deduced here.
Third, the experience of building it does not suggest that someone is actively preoccupied with this.
None of this is anyone's fault, obviously; on the contrary, I salute and deeply appreciate the developers of SEMS for giving us this wonderful work. However, I think it's important to avoid illusions about where the open-source edition is in the lifecycle.
-- Alex
On Dec 30, 2024, at 11:27 am, Henning Westerholt hw@gilawa.com wrote:
Hello Ben, yes, there are different PRs and smaller changes/fixes that gets merged. Juha is doing here some substantial work. We are having some customers that are using it, and we did some packaging for that. So far (with the SBC module for B2BUA) we did not observe any critical issues we needed to fix. Cheers, Henning From: Ben Kaufman via sr-users sr-users@lists.kamailio.org Sent: Montag, 30. Dezember 2024 16:19 To: sr-users@lists.kamailio.org Cc: Ben Kaufman bkaufman@bcmone.com Subject: [SR-Users] Re: how to call loose_route() after adding route header without using msg_apply_changes? ... As the latest changes seem to be within the last month. https://github.com/sems-server/sems Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768 From: Ben Kaufman bkaufman@bcmone.com Sent: Monday, December 30, 2024 9:18 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@evaristesys.com 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: bkaufman@bcmone.com
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 sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 7:37 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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:
Reoriginate call legs / relay requests;
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... 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.o...
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%2Fevaristesy... Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Indeed, I am probably being unfair in giving the short shrift to the existing dedication to SEMS that is valiantly upheld by a few members of the community, between Juha and Sipwise. I didn't mean to do that.
Having said that, I do not think the questions I have raised about SEMS' continuing viability as a platform dependency are unfounded.
One metric is the Sems mailing list:
https://www.mail-archive.com/sems@lists.iptel.org/info.html
Once upon a time, close to a decade ago, it was relatively lively, if only because Stefan Sayer more or less solely answered all questions and addressed all issues. It has been defunct since about 2016, more or less, and as far as I'm aware, the Google Group that was meant to replace it does not actually exist, at least anymore:
https://groups.google.com/d/forum/sems-users
Second, to the extent that commit volume or any derivatives thereof attest to the larger picture:
https://github.com/sems-server/sems/graphs/code-frequency
We know, of course, that quantity is not quality, that voluminous commits do not go on indefinitely at the same level even in actively maintained projects, and that this is not the only repo. Still, I think some kind of trend can be deduced here.
Third, the experience of building it does not suggest that someone is actively preoccupied with this.
None of this is anyone's fault, obviously; on the contrary, I salute and deeply appreciate the developers of SEMS for giving us this wonderful work. However, before marrying it, I think it's important to be free of any illusions about where the open-source edition is in its lifecycle.
-- Alex
On Dec 30, 2024, at 11:27 am, Henning Westerholt hw@gilawa.com wrote:
Hello Ben, yes, there are different PRs and smaller changes/fixes that gets merged. Juha is doing here some substantial work. We are having some customers that are using it, and we did some packaging for that. So far (with the SBC module for B2BUA) we did not observe any critical issues we needed to fix. Cheers, Henning From: Ben Kaufman via sr-users sr-users@lists.kamailio.org Sent: Montag, 30. Dezember 2024 16:19 To: sr-users@lists.kamailio.org Cc: Ben Kaufman bkaufman@bcmone.com Subject: [SR-Users] Re: how to call loose_route() after adding route header without using msg_apply_changes? ... As the latest changes seem to be within the last month. https://github.com/sems-server/sems Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768 From: Ben Kaufman bkaufman@bcmone.com Sent: Monday, December 30, 2024 9:18 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@evaristesys.com 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: bkaufman@bcmone.com
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 sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 7:37 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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:
Reoriginate call legs / relay requests;
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... 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.o...
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%2Fevaristesy... Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hello Alex,
completely agree.
I also would not recommend using SEMS in new projects without having a realistic expectation what to expect from the open-source project and some plan what to do when issues occur in production. Like, I can help myself or do I have somebody that offers support etc..
Cheers,
Henning
-----Original Message----- From: Alex Balashov via sr-users sr-users@lists.kamailio.org Sent: Montag, 30. Dezember 2024 18:00 To: sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@evaristesys.com Subject: [SR-Users] Re: how to call loose_route() after adding route header without using msg_apply_changes?
Indeed, I am probably being unfair in giving the short shrift to the existing dedication to SEMS that is valiantly upheld by a few members of the community, between Juha and Sipwise. I didn't mean to do that.
Having said that, I do not think the questions I have raised about SEMS' continuing viability as a platform dependency are unfounded.
One metric is the Sems mailing list:
https://www.mail-archive.com/sems@lists.iptel.org/info.html
Once upon a time, close to a decade ago, it was relatively lively, if only because Stefan Sayer more or less solely answered all questions and addressed all issues. It has been defunct since about 2016, more or less, and as far as I'm aware, the Google Group that was meant to replace it does not actually exist, at least anymore:
https://groups.google.com/d/forum/sems-users
Second, to the extent that commit volume or any derivatives thereof attest to the larger picture:
https://github.com/sems-server/sems/graphs/code-frequency
We know, of course, that quantity is not quality, that voluminous commits do not go on indefinitely at the same level even in actively maintained projects, and that this is not the only repo. Still, I think some kind of trend can be deduced here.
Third, the experience of building it does not suggest that someone is actively preoccupied with this.
None of this is anyone's fault, obviously; on the contrary, I salute and deeply appreciate the developers of SEMS for giving us this wonderful work. However, before marrying it, I think it's important to be free of any illusions about where the open-source edition is in its lifecycle.
-- Alex
On Dec 30, 2024, at 11:27 am, Henning Westerholt hw@gilawa.com
wrote:
Hello Ben, yes, there are different PRs and smaller changes/fixes that gets merged. Juha
is doing here some substantial work.
We are having some customers that are using it, and we did some packaging
for that. So far (with the SBC module for B2BUA) we did not observe any critical issues we needed to fix.
Cheers, Henning From: Ben Kaufman via sr-users sr-users@lists.kamailio.org Sent: Montag, 30. Dezember 2024 16:19 To: sr-users@lists.kamailio.org Cc: Ben Kaufman bkaufman@bcmone.com Subject: [SR-Users] Re: how to call loose_route() after adding route header
without using msg_apply_changes?
... As the latest changes seem to be within the last month. https://github.com/sems-server/sems Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support:
800.250.6510 | Flowroute Client Support: 855.356.9768
From: Ben Kaufman bkaufman@bcmone.com Sent: Monday, December 30, 2024 9:18 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@evaristesys.com 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: bkaufman@bcmone.com
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 sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 7:37 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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:
Reoriginate call legs / relay requests;
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:
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
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org 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 -- sr- users@lists.kamailio.org To unsubscribe send an email to sr-users- leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
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 sr-users@lists.kamailio.org wrote:
Not recommending for or against SEMS, but it does appear to be actively maintained, as the latest
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
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 sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 7:37 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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:
Reoriginate call legs / relay requests;
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... 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.o...
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%2Fevaristesy... Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
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 sr-users@lists.kamailio.org 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 sr-users@lists.kamailio.org wrote:
Not recommending for or against SEMS, but it does appear to be actively maintained, as the latest
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
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 sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 7:37 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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:
Reoriginate call legs / relay requests;
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... 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.o...
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%2Fevaristesy... Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hi Fred
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.
I used your example and we tried FreeSWITCH. Thank you for your suggestion.
Unfortunately we ran into massive issues we were not able to solve.
I don't exactly recall which one it was but it appeared in situations involving:
* 100rel required * parallel branches
It was either the issue that FreeSWITCH itself was dropping rseq replies with same rseq number but different totags wrongfully as duplicates.
Or it was the issue with those replies with different totags on the 2nd leg being mapped to ONE totag on the first leg causing the original sender to consider them a duplicates and dropping them.
Benoit,
You posted "rseq", but do you mean "cseq"? Is the issue you reference Freeswitch returning a 482 reply to a serial forked request?
Kaufman Senior Voice Engineer
E: bkaufman@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: Benoît Panizzon via sr-users sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 10:14 AM To: Fred Posner via sr-users sr-users@lists.kamailio.org Cc: Fred Posner fred@pgpx.io; Benoît Panizzon benoit.panizzon@imp.ch 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.
Hi Fred
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...https://github.com/fredposner/cluecon2023
I used your example and we tried FreeSWITCH. Thank you for your suggestion.
Unfortunately we ran into massive issues we were not able to solve.
I don't exactly recall which one it was but it appeared in situations involving:
* 100rel required * parallel branches
It was either the issue that FreeSWITCH itself was dropping rseq replies with same rseq number but different totags wrongfully as duplicates.
Or it was the issue with those replies with different totags on the 2nd leg being mapped to ONE totag on the first leg causing the original sender to consider them a duplicates and dropping them.
-- Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.imp.ch%...http://www.imp.ch/ ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
If you read 3262, there is, in fact, a concept of an RSeq that is 100rel-specific.
-- Alex
On Dec 30, 2024, at 2:22 pm, Ben Kaufman via sr-users sr-users@lists.kamailio.org wrote:
Benoit,
You posted "rseq", but do you mean "cseq"? Is the issue you reference Freeswitch returning a 482 reply to a serial forked request?
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768
From: Benoît Panizzon via sr-users sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 10:14 AM To: Fred Posner via sr-users sr-users@lists.kamailio.org Cc: Fred Posner fred@pgpx.io; Benoît Panizzon benoit.panizzon@imp.ch 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.
Hi Fred
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...
I used your example and we tried FreeSWITCH. Thank you for your suggestion.
Unfortunately we ran into massive issues we were not able to solve.
I don't exactly recall which one it was but it appeared in situations involving:
- 100rel required
- parallel branches
It was either the issue that FreeSWITCH itself was dropping rseq replies with same rseq number but different totags wrongfully as duplicates.
Or it was the issue with those replies with different totags on the 2nd leg being mapped to ONE totag on the first leg causing the original sender to consider them a duplicates and dropping them.
-- Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.imp.ch%... ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
That could be what he's referencing. Regarding forking (parallel or serial), Freeswitch has an issue with it. Going from memory (I could be mistaken) it rejects subsequent requests having the same call-id with a 482, despite the fact that the branch parameter of the Via: is different. Reported here:
https://freeswitch-users.freeswitch.narkive.com/pl2VL6Gu/482-request-merged-...
I know that thread is 15 years old, but I believe the behavior stands today. If that's the cause of either of the issues Benoit having, I'd like to mock it up and try reporting it to the freeswitch team again.
Kaufman Senior Voice Engineer
E: bkaufman@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 abalashov@evaristesys.com Sent: Monday, December 30, 2024 2:18 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Ben Kaufman bkaufman@bcmone.com Subject: Re: [SR-Users] 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.
If you read 3262, there is, in fact, a concept of an RSeq that is 100rel-specific.
-- Alex
On Dec 30, 2024, at 2:22 pm, Ben Kaufman via sr-users sr-users@lists.kamailio.org wrote:
Benoit,
You posted "rseq", but do you mean "cseq"? Is the issue you reference Freeswitch returning a 482 reply to a serial forked request?
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768
From: Benoît Panizzon via sr-users sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 10:14 AM To: Fred Posner via sr-users sr-users@lists.kamailio.org Cc: Fred Posner fred@pgpx.io; Benoît Panizzon benoit.panizzon@imp.ch 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.
Hi Fred
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...https://github.com/fredposner/cluecon2023
I used your example and we tried FreeSWITCH. Thank you for your suggestion.
Unfortunately we ran into massive issues we were not able to solve.
I don't exactly recall which one it was but it appeared in situations involving:
- 100rel required
- parallel branches
It was either the issue that FreeSWITCH itself was dropping rseq replies with same rseq number but different totags wrongfully as duplicates.
Or it was the issue with those replies with different totags on the 2nd leg being mapped to ONE totag on the first leg causing the original sender to consider them a duplicates and dropping them.
-- Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.imp.ch%...http://www.imp.ch/ ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800
I think this is a Sofia thing, and it's a problem in Drachtio land, too. At least, that's what I've heard.
On Dec 30, 2024, at 9:54 pm, Ben Kaufman bkaufman@bcmone.com wrote:
That could be what he's referencing. Regarding forking (parallel or serial), Freeswitch has an issue with it. Going from memory (I could be mistaken) it rejects subsequent requests having the same call-id with a 482, despite the fact that the branch parameter of the Via: is different. Reported here:
https://freeswitch-users.freeswitch.narkive.com/pl2VL6Gu/482-request-merged-...
I know that thread is 15 years old, but I believe the behavior stands today. If that's the cause of either of the issues Benoit having, I'd like to mock it up and try reporting it to the freeswitch team again.
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768
From: Alex Balashov abalashov@evaristesys.com Sent: Monday, December 30, 2024 2:18 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Ben Kaufman bkaufman@bcmone.com Subject: Re: [SR-Users] 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.
If you read 3262, there is, in fact, a concept of an RSeq that is 100rel-specific.
-- Alex
On Dec 30, 2024, at 2:22 pm, Ben Kaufman via sr-users sr-users@lists.kamailio.org wrote:
Benoit,
You posted "rseq", but do you mean "cseq"? Is the issue you reference Freeswitch returning a 482 reply to a serial forked request?
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768
From: Benoît Panizzon via sr-users sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 10:14 AM To: Fred Posner via sr-users sr-users@lists.kamailio.org Cc: Fred Posner fred@pgpx.io; Benoît Panizzon benoit.panizzon@imp.ch 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.
Hi Fred
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...
I used your example and we tried FreeSWITCH. Thank you for your suggestion.
Unfortunately we ran into massive issues we were not able to solve.
I don't exactly recall which one it was but it appeared in situations involving:
- 100rel required
- parallel branches
It was either the issue that FreeSWITCH itself was dropping rseq replies with same rseq number but different totags wrongfully as duplicates.
Or it was the issue with those replies with different totags on the 2nd leg being mapped to ONE totag on the first leg causing the original sender to consider them a duplicates and dropping them.
-- Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.imp.ch%... ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesy... Tel: +1-706-510-6800
Hi Ben
You posted "rseq", but do you mean "cseq"? Is the issue you reference Freeswitch returning a 482 reply to a serial forked request?
I don't fully recall which exact situation caused which issue with OpenSIPS or FreeSwitch. I just recall we had issues with the same situation.
And it's with the rseq sequence numbers we had the issue when the call was parallel forked to multiple devices:
Alice INVITE (support 100rel) => B2BUA => Bob 1 => Bob 2
Bob 1 (Require 100rel; rseq 1; ToTag: AAA) 180 RINGING Bob 2 (Require 100rel; rseq 1; ToTag: BBB) 180 RINGING
Either the issue was that the second 180 RINGING with the same rseq was dropped as duplicate despite having a different ToTag or the issue was that on Alices leg, being a separate transaction with it's own set of Call-ID FromTag and ToTag both 1800 RINGING ended up having the same ToTag and same rseq making them appear as real duplicates to Alice who would drop one.
I opened a bug report which was not commented on the OpenSIPS issue. https://github.com/OpenSIPS/opensips/issues/3431
So OpenSIPS was mapping the ToTag wrongly. So I am pretty sure that FreeSwitch was the issue with the duplicate rseq being dropped altogether.
Hi.
You could try yeti-switch as registrar + SBC. Internally, it uses forked SEMS(actively developed) as b2bua. There is 100rel support.
I can't call it lightweight(there is web UI/REST API + databases), but you don't need an additional RTP engine and the kamailio database (kamailio will be used as a simple load balancer).
On 30.12.24 18:14, Benoît Panizzon via sr-users wrote:
Hi Fred
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.
I used your example and we tried FreeSWITCH. Thank you for your suggestion.
Unfortunately we ran into massive issues we were not able to solve.
I don't exactly recall which one it was but it appeared in situations involving:
- 100rel required
- parallel branches
It was either the issue that FreeSWITCH itself was dropping rseq replies with same rseq number but different totags wrongfully as duplicates.
Or it was the issue with those replies with different totags on the 2nd leg being mapped to ONE totag on the first leg causing the original sender to consider them a duplicates and dropping them.
Given a call flowlike the one shown, you could consider using redirects from the registrar rather than passing traffic through the registrar. I agree that this does very much feel like a place where a B2BUA is appropriate given what may be a very non-standard implementation by another UA. With that said it's fairly cheap and easy to add more kamailio to any environment - even use alternate ports as needed and run it in a container.
Regards, Kaufman
________________________________ From: Alex Balashov via sr-users sr-users@lists.kamailio.org Sent: Monday, December 30, 2024 5:54 AM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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 2:39 am, Benoît Panizzon via sr-users sr-users@lists.kamailio.org wrote:
So the call flow is:
Alice => Registrar => Core => Registrar => Bob
The same call passes the registrar twice. This, as I observe (it's still possible I did something wrong), breaks topos and header get replaced the wrong way!
As far as I know, this situation badly cries out for a lightweight B2BUA. It's no accident that pretty much all SBCs are based on a B2BUA.
However, I could be mistaken...
-- Alex
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! K
Hello,
On 30.12.24 08:39, Benoît Panizzon via sr-users wrote:
[...]
So the call flow is:
Alice => Registrar => Core => Registrar => Bob
The same call passes the registrar twice. This, as I observe (it's still possible I did something wrong), breaks topos and header get replaced the wrong way!
context should help here, setting one between alice and core and another one between core and bob.
- https://www.kamailio.org/docs/modules/stable/modules/topos.html#topos.f.tps_...
Cheers, Daniels
Hi Alex
What about the PacketCable spec constrains you only to a single Route header? I have never heard of such a constraint, and if it existed, it would be a pretty damning violation of a mechanism very deeply infused into the heart of RFC 3261.
I did not read those specs. It's just information that was passed on to me by a colleagues who did read the specs.
But guessing, I might imagine how it came to this situation. Traditionally cable network modems using the DOCSIS standard user PacketCable Telephony, basically an extended MGCP. And MGCP is a point to point connection between the CPE and the MGCP Gateway which, as our very old telephony platform, was translating between MGCP and SS7.
SS7 has been mostly decommissioned and replaced by SIP on Voice Interconnections. So our latest voice platform was a gateway between SIP on interconnections with other VSP and MGCP to our PacketCable cablemodems optionally supporting SIP as an MGCP replacement. But that voice platform was a B2BUA so operating in a point to point manner to the PacketCable Cablemodems, so no need to support more than one router or RR header. And the SIP implementation of the platform hat too many flaws and could not keep up with modern requirements like spam filtering, adding custom header like geolocation now needed for NG112 in Switzerland. Anyway, we needed an additional B2BUA SBC in between our platform and our customer to properly backhaul RTP and to provide some protection to our core platform which could easily be DDOSed by TCP Synflood attacks.
Step 1: Replace old platform with Kamailio => Done! Step 2: Replace soon EOL SBC => This is where I am struggling.
I mean this with all due respect: once again, you're doing something very clever, but maybe a little too clever, perhaps so clever that you're the only Kamailio implementor on the planet who is doing it. When that happens, it is possible that 1) you and you alone have such unique problems, and must devise correspondingly intrepid and ingenious solutions, or 2) there is another (simpler) approach. I would encourage you to think more strategically and less tactically in these cases: perhaps it is programmatically possible, somehow, to solve the problem, but does it mean that it should be solved that way, or solved at all?
I need to solve the root problem: Replacing our soon EOL commercial SBC. How this is solved, I agree, there are several ways. The company who sold us this SBC would be very happy to sell me their newest model for big money and big recurring license fees. The costs alone would probably not even be the issue. The Issue is that I found too many flaws or limitations with their products. Even clear bugs but when I open a technical case, most of the time the reply I get is on the lines "This is how we implemented the product, we acknowledge it's a violation of SIP RFC and/or causes interop issues in situation X and/or with device Y, but as this was a design decision to implement it this way this is not a bug and will not be fixed"
So I rather would prefer to stick to open-source.
I cannot say what the better approach is in this case, but it's safe to say that no proxy should be storing and restoring the Route set. If you truly have a type of endpoint that does not implement the most basic elements of the SIP standard, perhaps a business decision should be taken to simply not support it?
We talk about the vendor which makes about 90% of the CPE in use at our customers. I have no option but to find a solution.
-
Alex Balashov -
Ben Kaufman -
Benoît Panizzon -
Daniel-Constantin Mierla -
Dmitry -
Fred Posner -
Henning Westerholt -
James Browne