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

Thanks, Henning. Yes it looks like the same issue. I see that Daniel pushed a commit an hour ago for this, so I'm going to test it right now if I can and see what I can find. James On Thu, 5 Sept 2024 at 06:19, Henning Westerholt &lt;hw(a)gilawa.com&gt; wrote: > > 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 > > >