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

Hello James, Thanks for sending the logs. I just briefly looked to the log files, at least the port 443 "wrong" scenario looks similar from the error message to the issue described here from somebody else: https://github.com/kamailio/kamailio/issues/3969 Cheers, Henning > -----Original Message----- > From: James Browne via sr-users &lt;sr-users(a)lists.kamailio.org&gt; > Sent: Mittwoch, 4. September 2024 12:23 > To: miconda(a)gmail.com > Cc: Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.kamailio.org&gt;rg>; James > Browne &lt;james(a)frideo.com&gt; > Subject: [SR-Users] Re: Setting $du to websocket-secure > > Thanks, Daniel > Here are attached the logs with timestamps. I made two tests, involving > INVITEs that differed only in the Call-ID and CSeq. > In each case, the logs include the time of the websocket connection being > made. There was no other traffic on the server during the test. > > ############### > INVITE > sip:moon@bobbywomack.invalid;alias=11.15.32.1~33333~6;transport=ws > SIP/2.0 > Via: SIP/2.0/UDP 192.168.25.4:5060;rport;branch=z9hG4bK-d8754z- > cc2c63344f5218d > Route: <sip:10.25.17.11;lr;r2=on> > Route: <sip:198.18.55.66:443;transport=ws;lr;r2=on> > From: <sip:+353877900000@someclient>;tag=1a56f142c2ed4d2f > To: <sip:+35315220000@sip.frideo.eu> > ############### > > In log "port-80.txt", there was a websocket connection open to non-TLS port > 80, and the INVITE was relayed over it. > In log "port-443.txt", there was a websocket connection open to TLS port 443, > and the INVITE wasn't relayed. > > The kamailio.cfg was effectively this. > ############################################# > tcp_connection_match=1 > request_route { > route(INITIAL_INVITE_OUTGOING); > } > route[INITIAL_INVITE_OUTGOING] { > loose_route_preloaded(); > handle_ruri_alias(); > xlog("L_NOTICE", "[$ci] P1052 About to relay WS call to $dd:$dp from $fs > ($$du is $du)\n"); > if (!t_relay_to("0x02")) { > xlog("L_WARN", "[$ci] P1052 Failed relaying WS call to $dd:$dp\n"); > t_reply("503", "Relaying over WS to next hop failed"); > } > exit; > } > ############################################# > > James > > On Tue, 3 Sept 2024 at 15:53, Daniel-Constantin Mierla > &lt;miconda(a)gmail.com&gt; wrote: > > > > 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). > > > > > > 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 > > > &lt;miconda(a)gmail.com&gt; 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 &lt;hw(a)gilawa.com&gt; > 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 &lt;sr-users(a)lists.kamailio.org&gt; > > >>>>> Sent: Donnerstag, 29. August 2024 13:35 > > >>>>> To: Kamailio (SER) - Users Mailing List > > >>>>> &lt;sr-users(a)lists.kamailio.org&gt; > > >>>>> Cc: James Browne &lt;james(a)frideo.com&gt; > > >>>>> 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 > > >> > > -- > > 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 > >