27 Dec
2024
27 Dec
'24
5:18 a.m.
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
______________________________________________________
27 Dec
27 Dec
7:08 a.m.
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(a)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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)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
28 Dec
28 Dec
12:02 p.m.
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(a)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(a)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(a)lists.kamailio.org
> > To unsubscribe send an email to sr-users-leave(a)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(a)lists.kamailio.org
> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the sender!
12:14 p.m.
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(a)frideo.com> wrote:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
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(a)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(a)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(a)lists.kamailio.org
>> To unsubscribe send an email to sr-users-leave(a)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(a)lists.kamailio.org
> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the sender!
30 Dec
30 Dec
2:39 a.m.
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
______________________________________________________
3:50 a.m.
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(a)lists.kamailio.org>
Sent: Montag, 30. Dezember 2024 08:39
To: James Browne via sr-users <sr-users(a)lists.kamailio.org>
Cc: Benoît Panizzon <benoit.panizzon(a)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(a)lists.kamailio.org To unsubscribe send an email to sr-users-
leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
6:54 a.m.
On Dec 30, 2024, at 2:39 am, Benoît Panizzon via
sr-users <sr-users(a)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://evaristesys.com
Tel: +1-706-510-6800
8:04 a.m.
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.
--
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
______________________________________________________
8:37 a.m.
On Dec 30, 2024, at 8:04 am, Benoît Panizzon
<benoit.panizzon(a)imp.ch> wrote:
Only issue: We have not found a B2BUA behaving the way we would like.
=> Any recommendations are very appreciated <=
There are basically two places we could put a B2BUA.
1: In front of the kamailio registrar (transparent registrar)
2: Between Registrar and our Routing Core
We have been burning through: [Asterisk, Sippy B2BUA, FreeSwitch, OpenSIPS, LibreSBC]
I can appreciate this frustration. A major part of the issue here is that some or all of
these systems--I am not equally familiar with all of them--are built on top of B2BUAs
architecturally, but are really designed to serve some other purpose (voice application
server, PBX system, pre-packaged SBC, etc). The mere fact that a system has a B2BUA under
the hood is not, per se, a necessary and sufficient precondition for suitability here.
What you need is a a really generic, signalling-only B2BUA whose sole purposes are:
1) Reoriginate call legs / relay requests;
2) Configure, in a fairly fine-grained way, the transparency or opacity with which
messages are passed between these.
We are historically fond of SEMS and its `sbc` module:
https://github.com/sems-server/sems/blob/master/doc/Readme.sbc.txt and I believe Sipwise
also maintain a fork of it for use inside their switch product ecology.
However, it is important to recognise that SEMS' community edition hasn't really
been actively maintained or developed in a very long time. It is nominally open-source,
but in practice serves as the back side of a commercial SBC product and gets very little
love besides. It has all the tell-tale signs of bit rot, starting with the fact that it
can be a bit challenging to build it on some modern Linux distributions. It's
difficult for me to endorse it wholeheartedly in 2025 as a way forward. This is a real
shame, because I think its `sbc` module fits your use-case almost like a glove.
On the other hand, if you're just trying to plug a short-term gap, bridge from legacy
to next-generation, etc., SEMS does still work, for the moment, despite undergoing
entropic decay. It might be viable yet.
It's possible that, with a little programming, Drachtio might fit the mold:
https://drachtio.org/docs
However, I have heard from others that Drachtio uses an ancient forked version of the
Sofia SIP stack internally, and that there some call forking issues with it. This is mere
hearsay; I've not independently verified it.
In terms of what you've tinkered with, you may just have to make some compromises, and
accept that you can't get everything you might want. If PRACK/100rel is the only thing
that stands in your way, just drop it. It's not very important, and the alternatives
are worse.
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
10:18 a.m.
Not recommending for or against SEMS, but it does appear to be actively maintained, as the
latest
Kaufman
Senior Voice Engineer
E: bkaufman(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)imp.ch> wrote:
Only issue: We have not found a B2BUA behaving the way we would like.
=> Any recommendations are very appreciated <=
There are basically two places we could put a B2BUA.
1: In front of the kamailio registrar (transparent registrar)
2: Between Registrar and our Routing Core
We have been burning through: [Asterisk, Sippy B2BUA, FreeSwitch, OpenSIPS, LibreSBC]
I can appreciate this frustration. A major part of the issue here is that some or all of
these systems--I am not equally familiar with all of them--are built on top of B2BUAs
architecturally, but are really designed to serve some other purpose (voice application
server, PBX system, pre-packaged SBC, etc). The mere fact that a system has a B2BUA under
the hood is not, per se, a necessary and sufficient precondition for suitability here.
What you need is a a really generic, signalling-only B2BUA whose sole purposes are:
1) Reoriginate call legs / relay requests;
2) Configure, in a fairly fine-grained way, the transparency or opacity with which
messages are passed between these.
We are historically fond of SEMS and its `sbc` module:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
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.…
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%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
10:19 a.m.
... As the latest changes seem to be within the last month.
https://github.com/sems-server/sems
Kaufman
Senior Voice Engineer
E: bkaufman(a)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(a)bcmone.com>
Sent: Monday, December 30, 2024 9:18 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)imp.ch> wrote:
Only issue: We have not found a B2BUA behaving the way we would like.
=> Any recommendations are very appreciated <=
There are basically two places we could put a B2BUA.
1: In front of the kamailio registrar (transparent registrar)
2: Between Registrar and our Routing Core
We have been burning through: [Asterisk, Sippy B2BUA, FreeSwitch, OpenSIPS, LibreSBC]
I can appreciate this frustration. A major part of the issue here is that some or all of
these systems--I am not equally familiar with all of them--are built on top of B2BUAs
architecturally, but are really designed to serve some other purpose (voice application
server, PBX system, pre-packaged SBC, etc). The mere fact that a system has a B2BUA under
the hood is not, per se, a necessary and sufficient precondition for suitability here.
What you need is a a really generic, signalling-only B2BUA whose sole purposes are:
1) Reoriginate call legs / relay requests;
2) Configure, in a fairly fine-grained way, the transparency or opacity with which
messages are passed between these.
We are historically fond of SEMS and its `sbc` module:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
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.…
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%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
10:20 a.m.
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(a)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(a)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(a)bcmone.com>
Sent: Monday, December 30, 2024 9:18 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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.
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
On Dec 30, 2024, at 8:04 am, Benoît Panizzon
<benoit.panizzon(a)imp.ch> wrote:
Only issue: We have not found a B2BUA behaving the way we would like.
=> Any recommendations are very appreciated <=
There are basically two places we could put a B2BUA.
1: In front of the kamailio registrar (transparent registrar)
2: Between Registrar and our Routing Core
We have been burning through: [Asterisk, Sippy B2BUA, FreeSwitch, OpenSIPS, LibreSBC]
I can appreciate this frustration. A major part of the issue here is that some or all of
these systems--I am not equally familiar with all of them--are built on top of B2BUAs
architecturally, but are really designed to serve some other purpose (voice application
server, PBX system, pre-packaged SBC, etc). The mere fact that a system has a B2BUA under
the hood is not, per se, a necessary and sufficient precondition for suitability here.
What you need is a a really generic, signalling-only B2BUA whose sole purposes are:
1) Reoriginate call legs / relay requests;
2) Configure, in a fairly fine-grained way, the transparency or opacity with which
messages are passed between these.
We are historically fond of SEMS and its `sbc` module:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
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.…
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%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
10:39 a.m.
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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 9:20 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)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.co…
Kaufman
Senior Voice Engineer
E: bkaufman(a)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(a)bcmone.com>
Sent: Monday, December 30, 2024 9:18 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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.
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 30, 2024, at 8:04 am, Benoît Panizzon
<benoit.panizzon(a)imp.ch> wrote:
Only issue: We have not found a B2BUA behaving the way we would like.
=> Any recommendations are very appreciated <=
There are basically two places we could put a B2BUA.
1: In front of the kamailio registrar (transparent registrar)
2: Between Registrar and our Routing Core
We have been burning through: [Asterisk, Sippy B2BUA, FreeSwitch, OpenSIPS, LibreSBC]
I can appreciate this frustration. A major part of the issue here is that some or all of
these systems--I am not equally familiar with all of them--are built on top of B2BUAs
architecturally, but are really designed to serve some other purpose (voice application
server, PBX system, pre-packaged SBC, etc). The mere fact that a system has a B2BUA under
the hood is not, per se, a necessary and sufficient precondition for suitability here.
What you need is a a really generic, signalling-only B2BUA whose sole purposes are:
1) Reoriginate call legs / relay requests;
2) Configure, in a fairly fine-grained way, the transparency or opacity with which
messages are passed between these.
We are historically fond of SEMS and its `sbc` module:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
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.…
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%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
11:27 a.m.
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(a)lists.kamailio.org>
Sent: Montag, 30. Dezember 2024 16:19
To: sr-users(a)lists.kamailio.org
Cc: Ben Kaufman <bkaufman(a)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<mailto: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<mailto:bkaufman@bcmone.com>>
Sent: Monday, December 30, 2024 9:18 AM
To: sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Cc: Alex Balashov
<abalashov@evaristesys.com<mailto: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<mailto: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<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Cc: Alex Balashov
<abalashov@evaristesys.com<mailto: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<mailto: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.co…
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.…
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%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
11:57 a.m.
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:

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(a)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(a)lists.kamailio.org>
Sent: Montag, 30. Dezember 2024 16:19
To: sr-users(a)lists.kamailio.org
Cc: Ben Kaufman <bkaufman(a)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(a)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(a)bcmone.com>
Sent: Monday, December 30, 2024 9:18 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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.
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
On Dec 30, 2024, at 8:04 am, Benoît Panizzon
<benoit.panizzon(a)imp.ch> wrote:
Only issue: We have not found a B2BUA behaving the way we would like.
=> Any recommendations are very appreciated <=
There are basically two places we could put a B2BUA.
1: In front of the kamailio registrar (transparent registrar)
2: Between Registrar and our Routing Core
We have been burning through: [Asterisk, Sippy B2BUA, FreeSwitch, OpenSIPS, LibreSBC]
I can appreciate this frustration. A major part of the issue here is that some or all of
these systems--I am not equally familiar with all of them--are built on top of B2BUAs
architecturally, but are really designed to serve some other purpose (voice application
server, PBX system, pre-packaged SBC, etc). The mere fact that a system has a B2BUA under
the hood is not, per se, a necessary and sufficient precondition for suitability here.
What you need is a a really generic, signalling-only B2BUA whose sole purposes are:
1) Reoriginate call legs / relay requests;
2) Configure, in a fairly fine-grained way, the transparency or opacity with which
messages are passed between these.
We are historically fond of SEMS and its `sbc` module:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
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.…
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%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
noon
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(a)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(a)lists.kamailio.org>
Sent: Montag, 30. Dezember 2024 16:19
To: sr-users(a)lists.kamailio.org
Cc: Ben Kaufman <bkaufman(a)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(a)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(a)bcmone.com>
Sent: Monday, December 30, 2024 9:18 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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.
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
On Dec 30, 2024, at 8:04 am, Benoît Panizzon
<benoit.panizzon(a)imp.ch> wrote:
Only issue: We have not found a B2BUA behaving the way we would like.
=> Any recommendations are very appreciated <=
There are basically two places we could put a B2BUA.
1: In front of the kamailio registrar (transparent registrar)
2: Between Registrar and our Routing Core
We have been burning through: [Asterisk, Sippy B2BUA, FreeSwitch, OpenSIPS, LibreSBC]
I can appreciate this frustration. A major part of the issue here is that some or all of
these systems--I am not equally familiar with all of them--are built on top of B2BUAs
architecturally, but are really designed to serve some other purpose (voice application
server, PBX system, pre-packaged SBC, etc). The mere fact that a system has a B2BUA under
the hood is not, per se, a necessary and sufficient precondition for suitability here.
What you need is a a really generic, signalling-only B2BUA whose sole purposes are:
1) Reoriginate call legs / relay requests;
2) Configure, in a fairly fine-grained way, the transparency or opacity with which
messages are passed between these.
We are historically fond of SEMS and its `sbc` module:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
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.…
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%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
3:47 p.m.
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(a)lists.kamailio.org>
Sent: Montag, 30. Dezember 2024 18:00
To: sr-users(a)lists.kamailio.org
Cc: Alex Balashov <abalashov(a)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
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.
On Dec 30, 2024, at 11:27 am, Henning Westerholt
<hw(a)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(a)lists.kamailio.org>
Sent: Montag, 30. Dezember 2024 16:19
To: sr-users(a)lists.kamailio.org
Cc: Ben Kaufman <bkaufman(a)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(a)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(a)bcmone.com>
Sent: Monday, December 30, 2024 9:18 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)imp.ch>
wrote:
Only issue: We have not found a B2BUA behaving the way we would like.
=> Any recommendations are very appreciated <=
There are basically two places we could put a B2BUA.
1: In front of the kamailio registrar (transparent registrar)
2: Between Registrar and our Routing Core
We have been burning through: [Asterisk, Sippy B2BUA, FreeSwitch,
OpenSIPS, LibreSBC]
I can appreciate this frustration. A major part of the issue here is that some
What you need is a a really generic, signalling-only B2BUA whose sole
purposes are:
1) Reoriginate call legs / relay requests;
2) Configure, in a fairly fine-grained way, the transparency or opacity with
which messages are passed between these.
We are historically fond of SEMS and its `sbc` module:
https://github.com/sems-server/sems/blob/master/doc/Readme.sbc.txt and
I believe Sipwise also maintain a fork of it for use inside their switch product
ecology.
However, it is important to recognise that SEMS' community edition hasn't
really been actively maintained or developed in a very long time. It is
nominally
open-source, but in practice serves as the back side of a commercial SBC
product and gets very little love besides. It has all the tell-tale signs of bit rot,
starting with the fact that it can be a bit challenging to build it on some modern
Linux distributions. It's difficult for me to endorse it wholeheartedly in 2025 as
a way forward. This is a real shame, because I think its `sbc` module fits your
use-case almost like a glove.
On the other hand, if you're just trying to plug a short-term gap, bridge from
legacy to next-generation, etc., SEMS does still work, for the moment, despite
undergoing entropic decay. It might be viable yet.
It's possible that, with a little programming, Drachtio might fit the mold:
https://drachtio.org/docs
However, I have heard from others that Drachtio uses an ancient forked
version of the Sofia SIP stack internally, and that there some call forking
issues
with it. This is mere hearsay; I've not independently verified it.
In terms of what you've tinkered with, you may just have to make some
compromises, and accept that you can't get everything you might want. If
PRACK/100rel is the only thing that stands in your way, just drop it. It's not
very important, and the alternatives are worse.
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com/
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org To unsubscribe send an email to
sr-users-leave(a)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(a)lists.kamailio.org To unsubscribe send an email to sr-users-
leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
10:39 a.m.
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(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)imp.ch> wrote:
Only issue: We have not found a B2BUA behaving the way we would like.
=> Any recommendations are very appreciated <=
There are basically two places we could put a B2BUA.
1: In front of the kamailio registrar (transparent registrar)
2: Between Registrar and our Routing Core
We have been burning through: [Asterisk, Sippy B2BUA, FreeSwitch, OpenSIPS, LibreSBC]
I can appreciate this frustration. A major part of the issue here is that some or all of
these systems--I am not equally familiar with all of them--are built on top of B2BUAs
architecturally, but are really designed to serve some other purpose (voice application
server, PBX system, pre-packaged SBC, etc). The mere fact that a system has a B2BUA under
the hood is not, per se, a necessary and sufficient precondition for suitability here.
What you need is a a really generic, signalling-only B2BUA whose sole purposes are:
1) Reoriginate call legs / relay requests;
2) Configure, in a fairly fine-grained way, the transparency or opacity with which
messages are passed between these.
We are historically fond of SEMS and its `sbc` module:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
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.…
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%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
11:04 a.m.
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(a)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
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
On Dec 30, 2024, at 10:18 AM, Ben Kaufman via
sr-users <sr-users(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 7:37 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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.
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 30, 2024, at 8:04 am, Benoît Panizzon
<benoit.panizzon(a)imp.ch> wrote:
Only issue: We have not found a B2BUA behaving the way we would like.
=> Any recommendations are very appreciated <=
There are basically two places we could put a B2BUA.
1: In front of the kamailio registrar (transparent registrar)
2: Between Registrar and our Routing Core
We have been burning through: [Asterisk, Sippy B2BUA, FreeSwitch, OpenSIPS, LibreSBC]
I can appreciate this frustration. A major part of the issue here is that some or all of
these systems--I am not equally familiar with all of them--are built on top of B2BUAs
architecturally, but are really designed to serve some other purpose (voice application
server, PBX system, pre-packaged SBC, etc). The mere fact that a system has a B2BUA under
the hood is not, per se, a necessary and sufficient precondition for suitability here.
What you need is a a really generic, signalling-only B2BUA whose sole purposes are:
1) Reoriginate call legs / relay requests;
2) Configure, in a fairly fine-grained way, the transparency or opacity with which
messages are passed between these.
We are historically fond of SEMS and its `sbc` module:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
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.…
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%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
11:14 a.m.
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://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 http://www.imp.ch
______________________________________________________
2:22 p.m.
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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 10:14 AM
To: Fred Posner via sr-users <sr-users(a)lists.kamailio.org>
Cc: Fred Posner <fred(a)pgpx.io>io>; Benoît Panizzon <benoit.panizzon(a)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.co…
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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
3:18 p.m.
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(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 10:14 AM
To: Fred Posner via sr-users <sr-users(a)lists.kamailio.org>
Cc: Fred Posner <fred(a)pgpx.io>io>; Benoît Panizzon <benoit.panizzon(a)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
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
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.co…
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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
9:54 p.m.
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(a)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(a)evaristesys.com>
Sent: Monday, December 30, 2024 2:18 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Ben Kaufman <bkaufman(a)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(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 10:14 AM
To: Fred Posner via sr-users <sr-users(a)lists.kamailio.org>
Cc: Fred Posner <fred(a)pgpx.io>io>; Benoît Panizzon <benoit.panizzon(a)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
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
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.co…
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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
10:33 p.m.
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(a)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(a)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(a)evaristesys.com>
Sent: Monday, December 30, 2024 2:18 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Ben Kaufman <bkaufman(a)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
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
On Dec 30, 2024, at 2:22 pm, Ben Kaufman via
sr-users <sr-users(a)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(a)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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 10:14 AM
To: Fred Posner via sr-users <sr-users(a)lists.kamailio.org>
Cc: Fred Posner <fred(a)pgpx.io>io>; Benoît Panizzon <benoit.panizzon(a)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
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800 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.co…
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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)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(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
31 Dec
31 Dec
2:50 a.m.
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.
--
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
______________________________________________________
30 Dec
30 Dec
6:14 p.m.
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.
Example:
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.
10:27 a.m.
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(a)lists.kamailio.org>
Sent: Monday, December 30, 2024 5:54 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)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(a)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%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
K
1:38 p.m.
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
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
2:30 a.m.
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.
--
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
______________________________________________________
6
days inactive
10
days old
28 comments
8 participants
participants (8)
-
Alex Balashov -
Ben Kaufman -
Benoît Panizzon -
Daniel-Constantin Mierla -
Dmitry -
Fred Posner -
Henning Westerholt -
James Browne