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
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
Hate to bump this, but still haven't reached a satisfactory resolution and would welcome any input.
On Feb 25, 2025, at 8:07 AM, Alex Balashov abalashov@evaristesys.com wrote:
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
Hello Alex,
Have you considered using add_contact_alias and handle_ruri_alias from the nathelper module?
add_contact_alias() can be invoked from REPLY routes and REQUEST routes.
Also, can you post some of your haproxy config as well? I'm curious about the timeouts.
David
On Tue, Mar 4, 2025 at 3:40 PM Alex Balashov via sr-users < sr-users@lists.kamailio.org> wrote:
Hate to bump this, but still haven't reached a satisfactory resolution and would welcome any input.
On Feb 25, 2025, at 8:07 AM, Alex Balashov abalashov@evaristesys.com
wrote:
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
-- 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@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hi,
I have considered the nathelper folk traditions, yes, but given that force_tcp_alias() works so splendidly for registration contact bindings, I assume there must be a way to adapt it to other requests. If that's not the case, I'll end up doing something like what you describe.
I'm just trying to figure out why it's necessary; the asymmetry between the advanced mapping capabilities for contact bindings vs. regular Contacts in replies seems far too stark. I'd prefer not to take two different, overlapping approaches. It might make sense to just use nathelper for everything.
-- Alex
On Mar 4, 2025, at 4:17 PM, David Tek via sr-users sr-users@lists.kamailio.org wrote:
Hello Alex,
Have you considered using add_contact_alias and handle_ruri_alias from the nathelper module?
add_contact_alias() can be invoked from REPLY routes and REQUEST routes.
Also, can you post some of your haproxy config as well? I'm curious about the timeouts.
David
On Tue, Mar 4, 2025 at 3:40 PM Alex Balashov via sr-users sr-users@lists.kamailio.org wrote: Hate to bump this, but still haven't reached a satisfactory resolution and would welcome any input.
On Feb 25, 2025, at 8:07 AM, Alex Balashov abalashov@evaristesys.com wrote:
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
-- 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@lists.kamailio.org To unsubscribe send an email to sr-users-leave@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@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-
Alex Balashov -
David Tek