Hello,
can you run with debug=3 in kamailio.cfg and attach all the debug messages printed by Kamailio in such case? It will help to figure out where it fails first to find properly the connection.
Cheers, Daniel
On 03.09.24 15:24, James Browne wrote:
Thanks for your continued answers, Daniel.
I have an edge proxy in front of the registrar. The edge proxy calls add_contact_alias() whenever a REGISTER is received over websocket (before relaying the REGISTER to the registrar).
- Today I tested swapping the order of the loose_route() and
handle_ruri_alias() functions, but the result was the same. Always if the RURI (after handle_ruri_alias() is called) has transport=ws in it, then kamailio won't deliver it over a TLS websocket connection (when tcp_connection_match is set).
- So how can I set the $du to specify what websocket-over-tls (rather
than websocket-over-tcp-without tls) should be used? The handle_ruri_alias() function does not achieve this when I test it. Remember that "transport=ws" is used for both WS and WSS.
James
On Mon, 2 Sept 2024 at 16:00, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I didn't have the time to go in details over this discussion, but if I got it right quickly, then:
- you can set $du to any SIP URI, where the transport parameter can be
whatever you want
- handle_ruri_alias() should be done after and loose-route processing.
The Route headers are about intermediary hops, not the end points, and therefore they have to be consumed first. The ruri-alias should be about endpoint, so handling it has to be done by the last SIP proxy before the endpoint, where there is no other intermediary SIP hop (proxy).
Cheers, Daniel
On 02.09.24 16:50, James Browne via sr-users wrote:
Thanks, Daniel The problem is specifically about sending traffic to websocket clients that have already established connections to my kamailio proxy.
Thanks, Henning You're right. That PR caused this problem, but it didn't really _create_ a bug but highlighted one that was already there. Before that PR, kamailio would relay traffic destined for a websocket client via a WSS connection, but it was working only due to two bugs that would cancel each other out. As far as I can tell, this is how it worked.
- Kamailio would see the transport=ws and decide it would relay the
message over a TCP Websocket connection to the customer's TCP port.
- Kamailio would see a TLS connection open using that customer-side
TCP port and relay what it was treating as a non-TLS message through a TLS connection. Of course, after that PR fixed the second bug, the first came to light.
Anyway, is there a way to set the $du to a TLS-websocket URI? If not, then this looks like a bug to me and I think I should log a bug report. I've tested this thoroughly already and have a good feel for it.
(Full disclosure: I was involved with that PR 3810 that Henning mentioned.)
James
On Fri, 30 Aug 2024 at 09:08, Henning Westerholt hw@gilawa.com wrote:
Hello James,
It sounds a bit like a similar issue that was fixed some time ago for overlapping TCP and TLS sockets: https://github.com/kamailio/kamailio/pull/3810
Cheers,
Henning
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com
-----Original Message----- From: James Browne via sr-users sr-users@lists.kamailio.org Sent: Donnerstag, 29. August 2024 13:35 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: James Browne james@frideo.com Subject: [SR-Users] Setting $du to websocket-secure
How can I set the destination URI for an INVITE to be a websocket-secure destination? Is it possible?
Summary I've a proxy with tcp_connection_match=1, but websocket URIs always have transport=ws (never transport=wss) in them, so relaying a call to a WSS connection always fails. I tested running kamailio 6.0.0-dev2 compiled from a commit made this week. This proxy server uses nathelper rather than outbound module.
Detail We know that "transport=ws" is used for both WS and WSS. I've a proxy server that receives an INVITE for a WSS destination, and this proxy supports both WS and WSS. This proxy server must have core parameter tcp_connection_match=1 set, and this leads the t_relay() to fail. When an INVITE comes, these are the steps.
- The URI is something like
sip:user@anonymous.invalid;alias=198.51.100.10~52833~6;transport=ws.
- First handle_ruri_alias() removes the alias (which has ~6 in it, for
wss) and sets the $du to something like sip:198.51.100.10:52833;transport=ws.
- Then loose_route_preloaded() processes the Route header fields and forces
the outbound socket to the TLS websocket one.
- Then t_relay() fails to relay the INVITE and responds with 477 or 500.
If, however, there's a non-TLS websocket connection open to the proxy, the INVITE would be erroneously relayed over that (using the wrong kamailio-side TCP port). I can go deeper with testing if required. I wonder whether this is a bug.
James __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, October 8-10, 2024 -- asipto.com