2 Sep
2024
2 Sep
'24
5:50 p.m.
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(a)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(a)lists.kamailio.org>
> Sent: Donnerstag, 29. August 2024 13:35
> To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
> Cc: James Browne <james(a)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(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe: