2 Sep
2024
2 Sep
'24
7 p.m.
Hello,
I didn't have the time to go in details over this discussion, but if I
got it right quickly, then:
1) you can set $du to any SIP URI, where the transport parameter can be
whatever you want
2) 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(a)gilawa.com> wrote:
--
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
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:
__________________________________________________________
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: