5 Sep
2024
5 Sep
'24
9:18 a.m.
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 <sr-users(a)lists.kamailio.org>
Sent: Mittwoch, 4. September 2024 12:23
To: miconda(a)gmail.com
Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>; James
Browne <james(a)frideo.com>
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
<miconda(a)gmail.com> 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
> <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
> >>
> --
> 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
>