30 Dec
2024
30 Dec
'24
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
______________________________________________________