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.