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
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
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
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@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@lists.kamailio.org Sent: Donnerstag, 29. August 2024 13:35 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: James Browne james@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@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
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@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@lists.kamailio.org Sent: Donnerstag, 29. August 2024 13:35 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: James Browne james@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@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@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
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@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:
- you can set $du to any SIP URI, where the transport parameter can be
whatever you want
- 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@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@lists.kamailio.org Sent: Donnerstag, 29. August 2024 13:35 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: James Browne james@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@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@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
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).
- 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).
- 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@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:
- you can set $du to any SIP URI, where the transport parameter can be
whatever you want
- 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@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@lists.kamailio.org Sent: Donnerstag, 29. August 2024 13:35 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: James Browne james@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@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@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
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@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).
- 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).
- 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@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:
- you can set $du to any SIP URI, where the transport parameter can be
whatever you want
- 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@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@lists.kamailio.org Sent: Donnerstag, 29. August 2024 13:35 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: James Browne james@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@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@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
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@lists.kamailio.org Sent: Mittwoch, 4. September 2024 12:23 To: miconda@gmail.com Cc: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; James Browne james@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@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).
- 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).
- 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@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:
- you can set $du to any SIP URI, where the transport parameter
can be whatever you want
- 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@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
> -----Original Message----- > From: James Browne via sr-users sr-users@lists.kamailio.org > Sent: Donnerstag, 29. August 2024 13:35 > To: Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > Cc: James Browne james@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@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@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
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@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@lists.kamailio.org Sent: Mittwoch, 4. September 2024 12:23 To: miconda@gmail.com Cc: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; James Browne james@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@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).
- 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).
- 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@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:
- you can set $du to any SIP URI, where the transport parameter
can be whatever you want
- 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@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@lists.kamailio.org >> Sent: Donnerstag, 29. August 2024 13:35 >> To: Kamailio (SER) - Users Mailing List >> sr-users@lists.kamailio.org >> Cc: James Browne james@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@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@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
Hi Daniel, Henning I tested the commit 60165196ad3144597c24eb9f7bb7fb0cd56f8c25 (which is the one after your fix https://github.com/kamailio/kamailio/commit/aa794581ecf105b5313d2f5b8bcfe516...).
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@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@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@lists.kamailio.org Sent: Mittwoch, 4. September 2024 12:23 To: miconda@gmail.com Cc: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; James Browne james@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@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).
- 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).
- 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@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:
- you can set $du to any SIP URI, where the transport parameter
can be whatever you want
- 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@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@lists.kamailio.org >>> Sent: Donnerstag, 29. August 2024 13:35 >>> To: Kamailio (SER) - Users Mailing List >>> sr-users@lists.kamailio.org >>> Cc: James Browne james@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@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@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
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/aa794581ecf105b5313d2f5b8bcfe516...).
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@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@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@lists.kamailio.org Sent: Mittwoch, 4. September 2024 12:23 To: miconda@gmail.com Cc: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; James Browne james@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@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).
- 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).
- 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@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@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@lists.kamailio.org >>>> Sent: Donnerstag, 29. August 2024 13:35 >>>> To: Kamailio (SER) - Users Mailing List >>>> sr-users@lists.kamailio.org >>>> Cc: James Browne james@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@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@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
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@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:
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/aa794581ecf105b5313d2f5b8bcfe516...).
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@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@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@lists.kamailio.org Sent: Mittwoch, 4. September 2024 12:23 To: miconda@gmail.com Cc: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; James Browne james@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@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@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@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@lists.kamailio.org >>>>> Sent: Donnerstag, 29. August 2024 13:35 >>>>> To: Kamailio (SER) - Users Mailing List >>>>> sr-users@lists.kamailio.org >>>>> Cc: James Browne james@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@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@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
-
Daniel-Constantin Mierla -
Henning Westerholt -
James Browne