BTW, wouldn't a sensible solution be to allow force_tcp_alias() to operate on replies? But as I understand the documentation, it only works on requests. Right?
— Sent from mobile, apologies for brevity and errors.
On Feb 22, 2025, at 5:51 PM, Alex Balashov abalashov@evaristesys.com wrote:
Hello,
I am converting a Kamailio WSS/TLS gateway to pure TCP, with an external HAProxy handling TLS termination and emitting the proxied connection as plain TCP. I am using the PROXYv2 protocol, with `tcp_accept_haproxy=yes`, to convey the upstream network and transport-layer reachability info into Kamailio.
I am trying to figure out best practices for mapping the contacts on those connections to the proxied connections themselves.
For registrations, tcp_force_alias() (with `tcp_accept_aliases=yes`) works well, and inbound calls go to the right place. However, I'm not quite sure what to do with other flows, such as, for example, in-dialog requests on inbound calls going to the TLS endpoints.
There are obviously a lot of possibilities, all or most of which I've tinkered with. These generally involve either {s.replace}-ing `;transport=tls` with `;transport=tcp` in the contacts received from the client, or using the traditional `nathelper` contact alias / RURI alias bag of tricks. However, I don't like the former solution because it leads to a non-compliant R-URI going to the endpoint (it's not the ;transport it sent in its contact), and I don't like the latter because it seems like there are too many moving parts.
When tcp_force_alias() works so well for registrations, there must be some small linchpin I'm missing for normal request-reply flows. What is it?
Thanks in advance!
-- Alex
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800