Kamailio Diameter Integration Exposed the Limits of Reusing SIP Assumptions
Kamailio felt familiar on the SIP side, but Diameter peer state and application routing forced me to treat the second protocol on its own terms.
Kamailio
My First Kamailio Lab Changed How I Thought About a SIP Server
Kamailio made it obvious that SIP routing, registration and media handling do not have to live inside one PBX process.
Anchoring RTP with rtpengine Solved a Different Problem Than SIP Routing
Kamailio could route the signaling perfectly while media still failed. rtpengine made the signaling path and media path explicit instead of treating them as one thing.
Kamailio Transactions: Why Stateful Forwarding Changed My SIP Debugging
Once I separated stateless forwarding from transaction-aware forwarding, retransmissions, replies and failure handling in Kamailio became much easier to reason about.
Routing Calls Across Two PBXs Without Turning Kamailio into a PBX
A two-PBX lab clarified the boundary between SIP routing at the proxy and dialplan or application behavior inside the PBX.
Record-Route Explained Why My BYE Took a Different Path
Initial SIP routing and in-dialog routing are different problems. Record-Route was the mechanism that made the proxy stay on the path after the call was established.
Using Redis Beside Kamailio Without Making Redis the Whole Architecture
Redis was useful for fast shared state in a SIP lab, but the important decision was which state belonged there and how the proxy behaved when it disappeared.
SIP over TLS: The Certificate Error Was More Useful Than the Green Lock
Moving SIP signaling to TLS exposed certificate names, trust chains and transport assumptions that UDP had allowed me to ignore.
A SIP Load Balancer Needs Dialog Awareness Somewhere
Distributing initial INVITEs is easy; keeping in-dialog requests on a valid path is where the architecture starts to matter.