sr-users April 2024

sr-users@lists.kamailio.org

69 participants
63 discussions

Via header force change protocol to TLS?

by Anthony Alba

I have kamailio behind a TLS termination proxy so the sockets are correctly deduced to be TCP. However the clients only talk TLS to the proxy and are confused when the top Via header added by Kamailio is TCP. Is there a way for Kamailio to forcibly pretend its protocol is TLS? Like advertised_address but "advertised_protocol" instead. (With pjsip testing: it has a flag use_tls which ignores TCP from Kamailio and continues to use the persistent TLS transport to proxy. Linphone fails because it tries to honor TCP in Via and is unable to establish TCP transport). BTW I am using t_relay_to_tcp so Kamailio will return traffic to the proxy as TCP even though the contact addresses specify transport=TLS.

1 month, 3 weeks

q_malloc.c:520 WARNINGs

by Joel Serrano

Hi, Does anyone know what this WARNING means or how to fix it? 2024-03-09T00:39:15.406674-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.406823-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.406973-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.407089-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.407178-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.407278-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.407375-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) It happens after running dp_translate(). These are my settings: debug=L_DBG debug=L_NOTICE memdbg=L_INFO memlog=L_INFO corelog=L_ERR mem_summary=12 log_stderror=no log_facility=LOG_LOCAL0 log_name="csbc" log_prefix="{$mt $hdr(CSeq) $ci} " mem_join=1 Any ideas? Thanks, Joel.

2 months, 1 week

dynamic selection of authentication algorithm

by Juha Heinanen

How about this new function that sets the algorithm? -- Juha iff --git a/src/modules/auth/auth_mod.c b/src/modules/auth/auth_mod.c index 534ad9e20f..4e3a584d22 100644 --- a/src/modules/auth/auth_mod.c +++ b/src/modules/auth/auth_mod.c @@ -74,6 +74,10 @@ int w_consume_credentials(struct sip_msg *msg, char *s1, char *s2); * Check for credentials with given realm */ int w_has_credentials(struct sip_msg *msg, char *s1, char *s2); +/* + * Set authentication algorithm + */ +int w_auth_algorithm(struct sip_msg *msg, char *alg, char* s2); static int pv_proxy_authenticate( struct sip_msg *msg, char *realm, char *passwd, char *flags); @@ -170,6 +174,8 @@ static cmd_export_t cmds[] = { REQUEST_ROUTE}, {"pv_auth_check", (cmd_function)w_pv_auth_check, 4, fixup_pv_auth_check, 0, REQUEST_ROUTE}, + {"auth_algorithm", w_auth_algorithm, 1, fixup_spve_null, 0, + REQUEST_ROUTE}, {"bind_auth_s", (cmd_function)bind_auth_s, 0, 0, 0}, {0, 0, 0, 0, 0, 0} @@ -475,6 +481,35 @@ int w_has_credentials(sip_msg_t *msg, char *realm, char *s2) return -1; } return ki_has_credentials(msg, &srealm); + +} +/** + * + */ +int w_auth_algorithm(sip_msg_t *msg, char* alg, char* s2) +{ + if (fixup_get_svalue(msg, (gparam_t*)alg, &auth_algorithm) < 0) { + LM_ERR("failed to get algorithm value\n"); + return -1; + } + + if (strcmp(auth_algorithm.s, "MD5") == 0) { + hash_hex_len = HASHHEXLEN; + calc_HA1 = calc_HA1_md5; + calc_response = calc_response_md5; + } + else if (strcmp(auth_algorithm.s, "SHA-256") == 0) { + hash_hex_len = HASHHEXLEN_SHA256; + calc_HA1 = calc_HA1_sha256; + calc_response = calc_response_sha256; + } + else { + LM_ERR("Invalid algorithm provided." + " Possible values are \"\", \"MD5\" or \"SHA-256\"\n"); + return -1; + } + + return 1; } #ifdef USE_NC

2 months, 1 week

How to use environment variable

by Pavan Kumar

Hi everyone, I am trying to assign environment variable as follows listen=udp:0.0.0.0:5060 advertise $env(MY_IP):5060 Looks like using the environment variable as above is an invalid configuration. Is there a way to use IP from env var to advertise. Even better, is there a way to use result in a stun query as an advertised address? Thank you, Pavan Kumar

2 months, 2 weeks

http_async_client and sl_send_reply()

by Masud Muborakshohi

Hello! I have a problem when sending a response sl_send_reply("415", "The other party does not support video calling!"); in route[HTTP_REPLY]. When I make a request using http_async_query() to send a push notification to a mobile device, I need to process the response from the push server and respond with a SIP message to the client. Before sending the request I do $http_req(suspend) = 0; What am I doing wrong? Why are $fU and $ru equal to null ? #processing HTTP responses route[HTTP_REPLY] { if ($http_ok && $http_rs == 200) { xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n"); xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n"); } else if($http_rs == 415 || $http_rs == "415") { xlog("L_ERR", "route[HTTP_REPLY]: caller: $fU phone: $ru error: $http_err)\n"); send_reply("415", "The other party does not support video calling!"); } else { xlog("L_ALERT", "route[HTTP_REPLY]: error $http_err)\n"); } #exit; }

2 months, 3 weeks

Kamailio works but voice is not present during the calls!

by christian.marinelli＠hotmail.it

Hi all, i have a problem with my Kamailio SIP Server. I set up a Kamailio SIP server in a virtual machine on a private network and i connect to this with a WireGuard VPN. The problem is that i can connect to the SIP server throught different clients and users and i can call the other users, the devices ring and i can answer to the calls but unfortunatly there is no audio during the call :( I can't understand why, it seems all si OK, a year ago i set up another SIP server with the same configuration and all works correctly with it. Can anyone help me to understand why? I can copy and paste here all the config files if you need it. Thank you so much in advance Christian

2 months, 3 weeks

Issue with serial call forking to same destination

by Mathias

Hi I've an issue with serial call forking and I hope somebody can help me... What I'm trying to reach: We are using Kamailio in a dynamic network with multiple nodes. The dialplan is implemented using the KEMI interface. The call routing is completely dynamic. At the moment, we are having call groups, which may contain 1 or more recipients. If the number of this call group is called, Kamailio is doing a parallel forking to all group participants. Now I'm trying to extend the feature, that if nobody hooks up, the call is forwarded to another number. This has been implemented with serial forking. So the dialplan adds branches for all call group members with a q value of 1 and the last branch is the failover number with a lower q value. The branching and failure route works fine. The problem: * I have a call group (G Bob 900101), with one participant (Bob 200102). * The group has a fail over number (if Bob doesn't hook up), which points again to Bob. I know that this use case doesn't make much sense, but it has been simplified to show the problem. The failover number can be anything also another call group which may contain one or more recipients from the first group again. * Alice (200101) calls the call group * The first node (10.0.1.1/10.64.0.1) receives the call and forks it to branch 1 Bob (202102) with q value 1.0 and to a second branch Bob (202102) with q value 0.5. fr_timer is set to 10s * The call is forwarded to node 2 (10.0.2.1/10.64.0.2), where Bob is registered. * The call is forwarded to Bobs device (Grandstream GXV3350) and the phone is ringing. * After 10s, the first node detects the 408 Request Timeout and switches to the second branch * The invite is sent to node 2 and Bobs device again. * Node 1 also sends a CANCEL to node 2 and Bobs device for the first branch. * The call in Bobs device is terminated * Now the problem, the device does not react to the second INVITE. And after the fr_inv_timer expires, the call is terminated with a 408 Request Timeout. I can see that the second INVITE contains another branch ID <ID>.1 compared to the first INVITE, which had <ID>.0. The CANCEL is also sent with <ID>.0. I've also tried with a Cisco 8861 3PCC and it doesn't work either. Compared to the Grandstream, the Cisco device returns an error 500 upon the second INVITE. Since both devices do not accept what I'm trying, I guess I'm doing something wrong... At the moment I'm a bit lost, what the problem could be. Does somebody have an idea what it is and how I could solve it? Following two SIP dumps from node 1 and node 2: Node 1: |Time | 10.0.1.128 | 10.64.0.1 | | | | 10.0.1.1 | | 10.0.2.1 | |2024-01-31 14:17:07.792784| INVITE SDP (g711A g7 | | |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> Call-ID:2102072978-5060-296@BA.A.B.BCI CSeq:2950 | |(47276) ------------------> (5061) | | | |2024-01-31 14:17:07.793060| 407 Proxy Authentica | | |SIP Status 407 Proxy Authentication Required | |(47276) <------------------ (5061) | | | |2024-01-31 14:17:07.796613| ACK | | | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2950 | |(47276) ------------------> (5061) | | | |2024-01-31 14:17:07.799045| INVITE SDP (g711A g7 | | |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> Call-ID:2102072978-5060-296@BA.A.B.BCI CSeq:2951 | |(47276) ------------------> (5061) | | | |2024-01-31 14:17:07.836471| 100 trying -- your c | | |SIP Status 100 trying -- your call is important to us | |(47276) <------------------ (5061) | | | |2024-01-31 14:17:07.865219| | | INVITE SDP (g711A g7 |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5061) | |2024-01-31 14:17:08.036334| | | 100 trying -- your c |SIP Status 100 trying -- your call is important to us | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:08.084421| | | 180 Ringing |SIP Status 180 Ringing | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:08.096834| 180 Ringing | | |SIP Status 180 Ringing | |(47276) <------------------ (5061) | | | |2024-01-31 14:17:18.099644| | | INVITE SDP (g711A g7 |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5061) | |2024-01-31 14:17:18.100099| | | CANCEL | |SIP CANCEL From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5061) | |2024-01-31 14:17:18.259375| | | 100 trying -- your c |SIP Status 100 trying -- your call is important to us | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:18.274841| | | 200 canceling |SIP Status 200 canceling | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:18.296942| | | 487 Request Terminat |SIP Status 487 Request Terminated | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:18.298630| | | ACK | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5061) | |2024-01-31 14:17:20.281602| | | 408 Request Timeout |SIP Status 408 Request Timeout | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:20.283433| | | ACK | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5061) | |2024-01-31 14:17:20.307343| 408 Request Timeout | | |SIP Status 408 Request Timeout | |(47276) <------------------ (5061) | | | |2024-01-31 14:17:20.309097| ACK | | | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | |(47276) ------------------> (5061) | | | Node 2: |Time | 10.64.0.1 | 10.64.0.2 | | | | 10.0.2.1 | | 10.0.2.128 | |2024-01-31 14:17:07.869305| INVITE SDP (g711A g7 | | |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> Call-ID:2102072978-5060-296@BA.A.B.BCI CSeq:2951 | |(54454) ------------------> (5061) | | | |2024-01-31 14:17:08.036009| 100 trying -- your c | | |SIP Status 100 trying -- your call is important to us | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:08.050848| | | INVITE SDP (g711A g7 |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5060) | |2024-01-31 14:17:08.054357| | 100 Trying| | |SIP Status 100 Trying | | |(5061) <-------------------------------------- (5060) | |2024-01-31 14:17:08.075422| | 180 Ringing | |SIP Status 180 Ringing | | |(5061) <-------------------------------------- (5060) | |2024-01-31 14:17:08.083887| 180 Ringing | | |SIP Status 180 Ringing | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:18.100359| INVITE SDP (g711A g7 | | |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> Call-ID:2102072978-5060-296@BA.A.B.BCI CSeq:2951 | |(54454) ------------------> (5061) | | | |2024-01-31 14:17:18.258947| 100 trying -- your c | | |SIP Status 100 trying -- your call is important to us | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:18.273819| | | INVITE SDP (g711A g7 |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5060) | |2024-01-31 14:17:18.274460| CANCEL | | | |SIP Request CANCEL CSeq:2951 | |(54454) ------------------> (5061) | | | |2024-01-31 14:17:18.274550| | | CANCEL | |SIP CANCEL From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5060) | |2024-01-31 14:17:18.274615| 200 canceling | | |SIP Status 200 canceling | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:18.277438| | 200 OK | | |SIP Status 200 OK | | |(5061) <-------------------------------------- (5060) | |2024-01-31 14:17:18.279335| | 487 Request Terminated | |SIP Status 487 Request Terminated | | |(5061) <-------------------------------------- (5060) | |2024-01-31 14:17:18.280785| | | ACK | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5060) | |2024-01-31 14:17:18.296312| 487 Request Terminat | | |SIP Status 487 Request Terminated | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:18.298900| ACK | | | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | |(54454) ------------------> (5061) | | | |2024-01-31 14:17:20.280965| 408 Request Timeout | | |SIP Status 408 Request Timeout | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:20.283730| ACK | | | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | |(54454) ------------------> (5061) | | | At the moment, I'm using Kamailio 5.5.4, but I also did a short try with a newer version (I guess it was 5.7.4). Both versions showed the same issue. Best regards Mathias

2 months, 3 weeks

Sudden TCP errors and shared memory spikes

by David Cunningham

Hello, We have a production Kamailio 5.2.7 server which has suddenly started reporting spikes in the shared memory use. When looking into this, we noticed that at the same time as the memory spikes Kamailio also logs a huge amount of errors like the following. Can anyone help with an explanation for what's going on? The xx.xx.52.202 address is the Kamailio server itself. We record historical numbers of network connections for the server overall, and that doesn't show any increase in the number of TCP connections, either at the time of the spikes or as a general trend. Thanks in advance! Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: ERROR: <core> [core/tcp_main.c:2703]: tcpconn_1st_send(): connect xx.xx.52.202:42726 failed (RST) Connection refused Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: ERROR: <core> [core/tcp_main.c:2711]: tcpconn_1st_send(): xx.xx.52.202:42726: connect & send for 0x14bbf44c9f40 failed: Connection refused (111) Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: ERROR: tm [../../core/forward.h:293]: msg_send_buffer(): tcp_send failed Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: WARNING: <core> [core/tcp_main.c:1149]: tcp_do_connect(): xx.xx.52.202:42726: could not find corresponding listening socket for xx.xx.52.202, using default... -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

2 months, 4 weeks

tls_threads_mode and app_python3 module

by Ihor Olkhovskyi

Hello, Just to confirm, as I quickly checked into a code of 5.8.x branch, there were no modification on app_python3 module to comply with tls_threads_mode mechanism? Asking this beforehand posting a bug, that if using a quite simple script into module, with tls_threads_mode = 2 Kamailio just hangs at the start and become unresponsive. And by simple I mean something like this class PyKamailio: def __init__(self): self.test = 1 def child_init(self, rank): """Executed by app_python module when a new worker process (child) is initialized by Kamailio.""" return 1 def mod_init(): """ Executed by app_python module when it is initialized by Kamailio.""" return PyKamailio() with tls_threads_mode = 1 and 3 it loads, but if add some HTTPS calls inside the script (even not the calls, but importing the methods, that are making calls with import), it just start failing on TLS load, despite that on packets processed (OPTIONS) no python_exec() is called, just from the fact of having HTTPS calls into Python script. -- Best regards, Ihor (Igor)

2 months, 4 weeks

RTP Engine with Kamailio hold issue

by Vishal Pai

Hello Everyone I am using kamailio with RTP engine for wss to udp to connect my asterisk server. It all works well like wss to UDP registration via kamailio to asterisk. Here I am facing an issue with call hold i.e if I hold the call from B leg it gets disconnected. Any advice why it get failed and hangups Thanks

2 months, 4 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users April 2024