29 Aug
2024
29 Aug
'24
7:35 a.m.
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
30 Aug
30 Aug
5:03 a.m.
Hello,
On 29.08.24 13:35, James Browne via sr-users wrote:
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.
Kamailio can act as a WebSocket server only (accept connections), so it
is not possible to forward SIP traffic via WebSocket if the connection
does not exist.
There is a module lwsc that implements a ws client using libwebsocket,
but that is designed for interconnect with external non-SIP servers
(e.g., right now can be used by rtpengine module).
Cheers, Daniel
--
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
5:08 a.m.
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:
2 Sep
2 Sep
10:50 a.m.
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:
noon
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:
3 Sep
3 Sep
9:24 a.m.
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:
--
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:
11:53 a.m.
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
4 Sep
4 Sep
6:22 a.m.
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
5 Sep
5 Sep
2: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
>
4:59 a.m.
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 <hw(a)gilawa.com> 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 <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
> >
11:26 a.m.
Hi Daniel, Henning
I tested the commit 60165196ad3144597c24eb9f7bb7fb0cd56f8c25 (which is
the one after your fix
https://github.com/kamailio/kamailio/commit/aa794581ecf105b5313d2f5b8bcfe51…).
Although this gets my particular test INVITE working over TLS, it's
not ideal because it can allow a WSS INVITE to be relayed over TCP and
also allow a WS INVITE to be relayed over TLS (I'm not a C coder, but
that's what I suspected when I read the commit, so I tested it). It
seems as if the alias part ~5 or ~6 (for WS or WSS) is not fully
respected.
It's this scenario (the security problem of a TLS message being sent
in the clear) for which PR 3810 (which Henning mentioned earlier) was
made. That was important because an SBC might make multiple TCP/TLS
connections on behalf of sub-customers and then a conflict can arise
if/when a port get reused/shared.
However, now I see these points.
- This change affects only websocket, so doesn't completely undo the
good of that PR.
- A full/complete fix, I expect, might be much more complicated,
because it would involve changing how $du works internally and involve
nathelper as well as core.
- Perhaps I'll deprecate the non-TLS websocket listener in my proxy
server and then this won't matter any more. I expect that this will
result in everything (Via transport parameter, Record-Route port, etc)
working perfectly.
Thanks for your quick fix on this. I think it's going to unblock a
kamailio upgrade for me.
James
On Thu, 5 Sept 2024 at 08:59, James Browne <james(a)frideo.com> wrote:
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 <hw(a)gilawa.com> 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 <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
> > >
11:54 a.m.
Hello,
the fix was done from the perspective that websocket is required to be
over secure transport if not on localhost (iirc), so first the lookup
was done for wss.
On the other hand, even if there are two connections, one ws and one
wss, the tuple (local-ip/port, remote-ip/port) should be different for
the two connections. I haven't gone deep in the code due to lack of
time, but if it is still something to look at, this is one direction.
Actually my commit came based on the hint (referenced commit there) from
the comment:
- https://github.com/kamailio/kamailio/issues/3969#issuecomment-2329630762
Cheers,
Daniel
On 05.09.24 17:26, James Browne wrote:
Hi Daniel, Henning
I tested the commit 60165196ad3144597c24eb9f7bb7fb0cd56f8c25 (which is
the one after your fix
https://github.com/kamailio/kamailio/commit/aa794581ecf105b5313d2f5b8bcfe51…).
Although this gets my particular test INVITE working over TLS, it's
not ideal because it can allow a WSS INVITE to be relayed over TCP and
also allow a WS INVITE to be relayed over TLS (I'm not a C coder, but
that's what I suspected when I read the commit, so I tested it). It
seems as if the alias part ~5 or ~6 (for WS or WSS) is not fully
respected.
It's this scenario (the security problem of a TLS message being sent
in the clear) for which PR 3810 (which Henning mentioned earlier) was
made. That was important because an SBC might make multiple TCP/TLS
connections on behalf of sub-customers and then a conflict can arise
if/when a port get reused/shared.
However, now I see these points.
- This change affects only websocket, so doesn't completely undo the
good of that PR.
- A full/complete fix, I expect, might be much more complicated,
because it would involve changing how $du works internally and involve
nathelper as well as core.
- Perhaps I'll deprecate the non-TLS websocket listener in my proxy
server and then this won't matter any more. I expect that this will
result in everything (Via transport parameter, Record-Route port, etc)
working perfectly.
Thanks for your quick fix on this. I think it's going to unblock a
kamailio upgrade for me.
James
On Thu, 5 Sept 2024 at 08:59, James Browne <james(a)frideo.com> wrote:
> 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 <hw(a)gilawa.com> 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 <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
>>>>
--
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
13 Sep
13 Sep
5:52 a.m.
Thanks, Daniel
I think the code is ok. I've tested it and it suits my needs. Are you
planning to backport it to a 5.8 version? I'm eager to get an upgrade
done, and to avoid a manual git patch if possible.
James
On Thu, 5 Sept 2024 at 15:54, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Hello,
the fix was done from the perspective that websocket is required to be
over secure transport if not on localhost (iirc), so first the lookup
was done for wss.
On the other hand, even if there are two connections, one ws and one
wss, the tuple (local-ip/port, remote-ip/port) should be different for
the two connections. I haven't gone deep in the code due to lack of
time, but if it is still something to look at, this is one direction.
Actually my commit came based on the hint (referenced commit there) from
the comment:
- https://github.com/kamailio/kamailio/issues/3969#issuecomment-2329630762
Cheers,
Daniel
On 05.09.24 17:26, James Browne wrote:
Hi Daniel, Henning
I tested the commit 60165196ad3144597c24eb9f7bb7fb0cd56f8c25 (which is
the one after your fix
https://github.com/kamailio/kamailio/commit/aa794581ecf105b5313d2f5b8bcfe51…).
Although this gets my particular test INVITE working over TLS, it's
not ideal because it can allow a WSS INVITE to be relayed over TCP and
also allow a WS INVITE to be relayed over TLS (I'm not a C coder, but
that's what I suspected when I read the commit, so I tested it). It
seems as if the alias part ~5 or ~6 (for WS or WSS) is not fully
respected.
It's this scenario (the security problem of a TLS message being sent
in the clear) for which PR 3810 (which Henning mentioned earlier) was
made. That was important because an SBC might make multiple TCP/TLS
connections on behalf of sub-customers and then a conflict can arise
if/when a port get reused/shared.
However, now I see these points.
- This change affects only websocket, so doesn't completely undo the
good of that PR.
- A full/complete fix, I expect, might be much more complicated,
because it would involve changing how $du works internally and involve
nathelper as well as core.
- Perhaps I'll deprecate the non-TLS websocket listener in my proxy
server and then this won't matter any more. I expect that this will
result in everything (Via transport parameter, Record-Route port, etc)
working perfectly.
Thanks for your quick fix on this. I think it's going to unblock a
kamailio upgrade for me.
James
On Thu, 5 Sept 2024 at 08:59, James Browne <james(a)frideo.com> wrote:
> 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 <hw(a)gilawa.com> 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 <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
>>>>
--
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
103
days inactive
118
days old
12 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Henning Westerholt -
James Browne