[SR-Users] Re: Setting $du to websocket-secure

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). 2) 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). 1) 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(a)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: > > 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: >>> 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: > > -- > 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 >