May 2024 - sr-dev - kamailio.org

[tracker] Assignee added: Assignment operators don't work
by sip-router 12 Jun '25

12 Jun '25

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#100 - Assignment operators don't work User who did this - Alex Hermann (axlh) http://sip-router.org/tracker/index.php?do=details&task_id=100 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

2 1

[kamailio/kamailio] Inactive video stream: can't find media IP in the message (Issue #3406)
by schoberw 31 May '25

31 May '25

### Description In some situations the other side UA must reply with an inactive media stream. E.g. if video was added but not supported by the other side. The UAS then must answer with an m=video 0 RTP/.. line. It seams that the video section must contain a c= line with an IP address for rtpengine to function. If there is no c line (no IP address) the SDP body cannot be parsed and thus no RTP proxy is invoked. ### Troubleshooting Not easy to reproduce since the answer must bei "wrong". Is it correct to reply an SDP body (media = video) like this? ``` m=video 0 RTP/AVPF 96 a=label:1 a=inactive a=mid:1 ``` Maybe not (but Audiocodes SBC lates LTS version does it) - so we are dependent on other side now that this service works. #### Reproduction reInvite with Video to a UA that has no video Support (e.g. Bria -> Snom). Drop the c line in the video part with some textops in 200 OK (just to reproduce of course). A -> B, connect the call A -> + video, B has no video support A presses hold #### Log Messages Incoming 200 OK after doing hold with an inactive video: ``` v=0 o=root 436040161 309284577 IN IP4 1.2.3.5 s=call t=0 0 m=audio 14200 RTP/AVPF 9 8 126 c=IN IP4 1.2.3.5 a=ptime:20 a=recvonly a=mid:0 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:126 telephone-event/8000 a=fmtp:126 0-15 m=video 0 RTP/AVPF 96 a=label:1 a=inactive a=mid:1 Mar 27 17:52:22 c5p05es2-1 /usr/sbin/kamailio[2938205]: ERROR: <core> [core/parser/sdp/sdp.c:490]: parse_sdp_session(): can't find media IP in the message Mar 27 17:52:22 c5p05es2-1 /usr/sbin/kamailio[2938205]: INFO: <script>: >>> Sending Reply: 200 OK (1.2.3.4:443 -> 100.108.48.38:65251) ``` Compare to working SDP parsing: ``` a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:126 telephone-event/8000 a=fmtp:126 0-15 m=video 0 RTP/AVP 96 c=IN IP4 1.2.3.5 a=inactive a=mid:1 Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: ONREPLY_ROUTE[FORWARD] Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: ROUTE[RTPP_REPLY] Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > 200 with video Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > 200 with inactive video Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > Remove inactive video Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > Answer to WebRTC client: 200 - qijpuibkv6ufhnd282ks Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: >>> Sending Reply: 200 OK (91.237.65.14:443 -> 80.108.48.38:65388) ``` ### Possible Solutions Tried to fix in script: ``` if(sdp_with_media("video")) xlog("L_INFO", "> $rs with video"); if(sdp_with_active_media("video")) xlog("L_INFO", "> $rs with active video"); if(!sdp_with_active_media("video")) xlog("L_INFO", "> $rs with inactive video"); if(sdp_with_media("video") && !sdp_with_active_media("video")) { # try fix for RMT#60189 xlog("L_INFO", "> Remove inactive video"); sdp_remove_media("video"); msg_apply_changes(); # needed? } ``` But since sdpops cannot parse it cannot remove the buggy media, too. See the log: non of the xlog is logging. If there is inactive media the c line is not mandatory. The parser should accept this by adding a default IP of 0.0.0.0, if needed Doing tricks with textops is not a easy nor performant solution to accept this wrong SDP from other parties. ### Additional Information ``` version: kamailio 5.6.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 10.2.1 ``` * **Operating System**: Debian Bullseye -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3406 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3406(a)github.com>

3 5

[kamailio/kamailio] Memory usage increases everytime tls.reload is executed (Issue #3823)
by Sebastian Denz 06 May '25

06 May '25

### Description We are using Kamailio 5.7.4 on Debian 12 (from http://deb.kamailio.org/kamailio57) with rtpengine as an Edgeproxy for our clients. The instance terminates SIP/TLS (with Cliencertificates) and forwards the SIP Traffic to internal systems. After some days we are getting errors like this `tls_complete_init(): tls: ssl bug #1491 workaround: not enough memory for safe operation: shm=7318616 threshold1=8912896` First we thought Kamailio just doesnt have enough memory, so we doubled it.. But after some days the Logmessage (and Userissues) occured again. So we monitored the shmmem statistics and found that used and max_used are constantly growing til it reaches the limit. As i mentioned we are using client-certificates and so we are also using the CRL feature. We do have a systemd-timer which fetches the CRL every hour and runs 'kamcmd tls.reload' when finished. Our tls.cfg looks like this: ``` [server:default] method = TLSv1.2+ private_key = /etc/letsencrypt/live/hostname.de/privkey.pem certificate = /etc/letsencrypt/live/hostname.de/fullchain.pem ca_list = /etc/kamailio/ca_list.pem ca_path = /etc/kamailio/ca_list.pem crl = /etc/kamailio/combined.crl.pem verify_certificate = yes require_certificate = yes [client:default] verify_certificate = yes require_certificate = yes ``` After testing a bit we found that every time tls.reload is executed Kamailio consumes a bit more memory which eventually leads to all the memory being consumed which leads to issues for our users. See following example: ``` [0][root@edgar-dev:~]# while true ; do /usr/sbin/kamcmd tls.reload ; /usr/sbin/kamcmd core.shmmem ; sleep 1 ; done Ok. TLS configuration reloaded. { total: 268435456 free: 223001520 used: 41352552 real_used: 45433936 max_used: 45445968 fragments: 73 } Ok. TLS configuration reloaded. { total: 268435456 free: 222377960 used: 41975592 real_used: 46057496 max_used: 46069232 fragments: 78 } Ok. TLS configuration reloaded. { total: 268435456 free: 221748664 used: 42604992 real_used: 46686792 max_used: 46698080 fragments: 77 } Ok. TLS configuration reloaded. { total: 268435456 free: 221110832 used: 43242408 real_used: 47324624 max_used: 47335608 fragments: 81 } ^C [130][root@edgar-dev:~]# ``` ### Troubleshooting #### Reproduction Everytime tls.reload is called the memory consumptions grows.. #### Debugging Data  ``` If you let me know what would be interesting for tracking this down, i am happy to provide logs/debugging data! ``` #### Log Messages  ``` If you let me know what would be interesting for tracking this down, i am happy to provide logs/debugging data! ``` #### SIP Traffic SIP doesnt seem to be relevant here ### Possible Solutions Calling tls.reload less often or restart kamailio before memory is consumed ;) ### Additional Information ``` version: kamailio 5.7.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ``` * **Operating System**: ``` * Debian GNU/Linux 12 (bookworm) * Linux edgar-dev 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3823 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3823(a)github.com>

9 31

[kamailio/kamailio] clean_sa(): Error sending delete SAs command via netlink socket: Invalid argument (#2707)
by openspring 16 Apr '25

16 Apr '25

### Description  #### Log Messages  ``` 0(117561) DEBUG: <core> [core/route_struct.c:128]: mk_action(): ACTION type5, i/count 0/1: type 1(1)/ data 0x7f8583620ef0 0(117561) DEBUG: <core> [core/route_struct.c:128]: mk_action(): ACTION type16, i/count 0/3: type 22(16)/ data 0x7f8583621ad8 0(117561) DEBUG: <core> [core/route_struct.c:128]: mk_action(): ACTION type16, i/count 1/3: type 8(8)/ data 0x7f8583620fd8 0(117561) DEBUG: <core> [core/route_struct.c:128]: mk_action(): ACTION type16, i/count 2/3: type 0(0)/ data 0x7f8500000000 0(117561) DEBUG: <core> [core/route.c:129]: route_add(): mapping routing block (0xb914c0)[MT_indialog_reply] to 6 ERROR: bad config file (1 errors) 0(117561) DEBUG: <core> [core/sr_module.c:765]: destroy_modules(): starting modules destroy phase 0(117561) DEBUG: debugger [debugger_api.c:1267]: dbg_destroy_mod_levels(): Destroyed _dbg_mod_table, size 32 0(117561) ERROR: ims_ipsec_pcscf [ipsec.c:567]: clean_sa(): Error sending delete SAs command via netlink socket: Invalid argument 0(117561) WARNING: ims_ipsec_pcscf [cmd.c:998]: ipsec_cleanall(): Error cleaning IPSec Security associations during startup. 0(117561) ERROR: ims_ipsec_pcscf [ipsec.c:609]: clean_policy(): Error sending delete policies command via netlink socket: Invalid argument 0(117561) WARNING: ims_ipsec_pcscf [cmd.c:1002]: ipsec_cleanall(): Error cleaning IPSec Policies during startup. 0(117561) ERROR: ims_ipsec_pcscf [ims_ipsec_pcscf_mod.c:309]: mod_destroy(): Error destroying spi generator 0(117561) ERROR: ims_ipsec_pcscf [ims_ipsec_pcscf_mod.c:313]: mod_destroy(): Error destroying port generator 0(117561) DEBUG: tm [t_funcs.c:84]: tm_shutdown(): start 0(117561) DEBUG: tm [t_funcs.c:87]: tm_shutdown(): emptying hash table 0(117561) DEBUG: tm [t_funcs.c:89]: tm_shutdown(): removing semaphores 0(117561) DEBUG: tm [t_funcs.c:91]: tm_shutdown(): destroying tmcb lists 0(117561) DEBUG: tm [t_funcs.c:94]: tm_shutdown(): done 0(117561) INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized 0(117561) DEBUG: <core> [core/mem/shm.c:289]: shm_destroy_manager(): destroying memory manager: q_malloc 0(117561) DEBUG: <core> [core/mem/q_malloc.c:1185]: qm_shm_lock_destroy(): destroying the shared memory lock 0(117561) DEBUG: <core> [core/mem/pkg.c:98]: pkg_destroy_manager(): destroying memory manager: q_malloc ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.4.4 (x86_64/linux) 8d6c2b flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 8d6c2b compiled on 22:26:30 Apr 11 2021 with gcc 4.8.5 ``` * **Operating System**:  ``` NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2707

5 5

[kamailio/kamailio] topos: add enable_register_publish (PR #3766)
by Harish S 09 Mar '25

09 Mar '25

Added enable_register_publish parameter to enable REGISTER and PUBLISH method for topos If set to 1 REGISTER and PUBLISH will be enabled for topos Currently only via header will be applied for topos and if mask_callid is set to 1 call-ID will be masked. Other headers should be manged by the user as required.   #### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3766 -- Commit Summary -- * add enable_register_publish -- File Changes -- M src/modules/topos/topos_mod.c (2) M src/modules/topos/tps_msg.c (132) M src/modules/topos/tps_msg.h (2) M src/modules/topos/tps_storage.c (6) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3766.patch https://github.com/kamailio/kamailio/pull/3766.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3766 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3766(a)github.com>

5 39

[kamailio/kamailio] Wrong Route header order in called party re-INVITE when using topos (Issue #3778)
by Javi Montoro 24 Feb '25

24 Feb '25

Hi There, We found a situation where topos seems to break, let me explain... Assuming the following scenario: ``` Caller ---- Callee A: ------INVITE-----> Record-Route:A.A.A.A, Record-Route:B.B.B.B B: <-----200 OK------ C: <-----INVITE------ Route: A.A.A.A, B.B.B.B D: ------200 OK-----> Record-Route:B.B.B.B, Record-Route:A.A.A.A (reversed order) E: <======INVITE===== Route: B.B.B.B, A.A.A.A (wrong) ``` A and B establish the connection from caller to callee, and topos works fine. C (re-INVITE from callee) sends the Route header according to the Record-Routes from the original INVITE (A) D is the 200 OK sent from the caller to the first re-INVITE (C) coming from the callee, with the Record-Route headers reversed, because is the order in which the callee received them; and according to the RFC it's working as intended: ``` When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. [...] [When a UAC receives a response...] The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. ``` E takes the Route order from the last 200 OK ignoring they are in reversed order and assuming the top one is the first one, when it should be the other way around, sending to an IP address not reachable from the callee. And I think here is the issue, topos should not update the path on the Record-Routes from a 200 OK but if it does, it should take the reverse order When disabling topos, everything works fine, or with topos enabled, by setting rr_update=0 works for us, but what if there is a real path update, rr_update=0 wouldn't work for us anymore. The Kamailio version is 5.8.0-rc0 Let me know if you need more information. Thanks a lot, Javi -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3778 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3778(a)github.com>

5 16

[kamailio/kamailio] Close parenthesis on error description (#2589)
by Javier Valencia 20 Jan '25

20 Jan '25

Close parentheses on error description when *Not enough parameters* on *htable_rpc_delete*. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2589 -- Commit Summary -- * Close parenthesis on error description -- File Changes -- M src/modules/htable/htable.c (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2589.patch https://github.com/kamailio/kamailio/pull/2589.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/2589

3 4

[kamailio/kamailio] free_fixup functions in cmd_export_t are not called (Issue #3814)
by Xenofon Karamanos 06 Dec '24

06 Dec '24

### Description It seems that the fixup_free_* functions are not getting called when used with: ``` static cmd_export_t cmds[] = { {"acc_log_request", (cmd_function)w_acc_log_request, 1, acc_fixup, free_acc_fixup, ANY_ROUTE}, // ... {0, 0, 0, 0, 0, 0} }; static int free_acc_fixup(void **param, int param_no) { LM_CRIT("acc free fixup = %d\n", param_no); if(*param) { pkg_free(*param); *param = 0; } return 0; } ``` Nothing is getting logged from the function. Is this expected not to print in free_fixup due to the destruction of kamailio and the logging is not reliable? I also used gdb and added some breakpoints in `fixup` and `free_fixup` functions in some other modules (file_out) and the breakpoint was only found in `fixup` but not in `free_fixup`. When is the `free_fixup` supposed to be called, at kamailio destruction or after fixing it and before the main loop starts?  ### Troubleshooting #### Reproduction  Use any module that has a custom (maybe also provided from core) `free_fixup` function, and monitor if `free_fixup` is called using debug mode. #### Log Messages  ``` Apr 15 15:52:03 app01 kamailio[812169]: INFO: <core> [core/mem/q_malloc.c:402]: qm_malloc(): qm_malloc(0x7fcdcab18010, 56) called from file_out: file_out.c: fo_fixup_str_index(287) Apr 15 15:52:03 app01 kamailio[812169]: INFO: <core> [core/mem/q_malloc.c:449]: qm_malloc(): qm_malloc(0x7fcdcab18010, 64) returns address 0x7fcdcacc4280 frag. 0x7fcdcacc4240 (size=64) on 1 -th hit``` `0x7fcdcacc4240` fragment is not found anywhere in the logs reported that it was freed unlike other malloced resources. ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.9.0-dev0 (x86_64/linux) 8bc64a flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 8bc64a compiled on 15:32:09 Apr 15 2024 with gcc 10.5.0 ``` * **Operating System**:  ``` No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.6 LTS Release: 20.04 Codename: focal 5.4.0-176-generic #196-Ubuntu SMP Fri Mar 22 16:46:39 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3814 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3814(a)github.com>

3 9

[kamailio/kamailio] no corresponding socket found error (Issue #3583)
by descartin 16 Nov '24

16 Nov '24

Hello all we are seeing these kind of logs in a Debian GNU/Linux 11 using kamailio 5.5.6 ```Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155702]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[164.152.22.248:5060](http://164.152.22.248:5060/)) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155698]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.184:5060](http://208.74.138.184:5060/)) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155695]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.181:5060](http://208.74.138.181:5060/)) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155693]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[38.102.250.60:5060](http://38.102.250.60:5060/)) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[87.1.1.27:5060](http://87.1.1.27:5060/)) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [ut.h:302]: uri2dst2(): no corresponding socket for "87.1.1.27" af 2 Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [t_fwd.c:470]: prepare_new_uac(): can't fwd to af 2, proto 1 (no corresponding listening socket) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155697]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.184:5060](http://208.74.138.184:5060/)) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155694]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[192.40.216.97:5060](http://192.40.216.97:5060/)) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155694]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.180:5060](http://208.74.138.180:5060/)) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155714]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[87.1.1.27:5060](http://87.1.1.27:5060/)) ``` The kamailio instance we are using is receiving around 1500 calls per second in average when we do start seeing these errors more frequently In this instance we are using multihomed the listen address list is ``` children=14 socket_workers=1 listen=udp:[192.168.99.70:5081](http://192.168.99.70:5081/) listen=udp:[192.168.99.81:5060](http://192.168.99.81:5060/) listen=udp:[87.1.1.27:5060](http://87.1.1.27:5060/) listen=tcp:[192.168.96.105:8095](http://192.168.96.105:8095/) listen=tcp:[87.1.1.27:5060](http://87.1.1.27:5060/) tcp_children=6 port=5060 ``` We use the first worker only to perform the OPTIONS requests from the dispatcher module. The sockets listen=udp:[192.168.99.81:5060](http://192.168.99.81:5060/) listen=udp:[87.1.1.27:5060](http://87.1.1.27:5060/) are used to communicate both A and B legs so when a message is received at [192.168.99.81:5060](http://192.168.99.81:5060/) we send it to [87.1.1.27:5060](http://87.1.1.27:5060/) and viceversa We were using $fs variable before doing the t_relay() function. This way is working, but when load increases, seems sometimes kamailio doesn't get the proper socket to forward the reply. I think the errors mainly are related to responses which are being forwarded, like if the function get_sock_info_list was not able to retrieve the listen interfaces we have tried to set in the onreply routes the commands set_recv_socket("udp:[192.168.99.81:5060](http://192.168.99.81:5060/)"); set_send_socket("udp:[87.1.1.27:5060](http://87.1.1.27:5060/)"); (when reply goes from private to public domain) and it seems it reduces the number of ``` Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155702]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[164.152.22.248:5060](http://164.152.22.248:5060/)) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155698]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.184:5060](http://208.74.138.184:5060/)) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155695]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.181:5060](http://208.74.138.181:5060/)) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155693]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[38.102.250.60:5060](http://38.102.250.60:5060/)) errors ``` But i honestly don't know why the ```Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [ut.h:302]: uri2dst2(): no corresponding socket for "87.1.1.27" af 2 Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [t_fwd.c:470]: prepare_new_uac(): can't fwd to af 2, proto 1 (no corresponding listening socket) appear ``` We also tried to increase the kernel buffers rmem and wmem from 208KB (as we had by default) to 4MB Do you know a reason which could cause these logs to appear? Any setup that could mitigate them? thanks a lot and regards david escartin -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3583 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3583(a)github.com>

5 6

[kamailio/kamailio] BUG: freeing already freed pointer (0x7f19a3edec68), called from tls: tls_init.c with random core dumps (Issue #3205)
by Tim Chubb 08 Nov '24

08 Nov '24

### Description  Im getting frequent log entries like this: `CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f19a3edec68), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring` This on a fresh VM running Ubuntu 22.04 LTS on the 5.6 branch (building latest release tag) As well as that log message being printed on a frequent basis (every 2 to 3 mins) i am experiencing random crashes/restarts of kamailio. Looking at the core dumps tls_init seems to precipitate the core dump. I have tried using both the TLS module, and TLSA, in the case of TLSA to rule out OpenSSL3 being an issue i have tried linking against locally built OpenSSL 3.0.5 and OpenSSL 1.1.1q with identical results I am in the process of repeating the build on Ubuntu 20.04 LTS to rule out weirdness with packages and similar issues i have experienced whilst evaluating 22.04 LTS ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (gdb) bt full #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140425701996352) at ./nptl/pthread_kill.c:44 tid = <optimized out> ret = 0 pd = 0x7fb76815b740 old_mask = {__val = {523986010119, 910533066753, 1, 140425395047168, 94230980435360, 0, 5677797456, 140425395047168, 140725986283600, 140425393986269, 94230963279192, 140425395047168, 94230963279402, 7970739754, 140725986283664, 140425394028321}} ret = <optimized out> pd = <optimized out> old_mask = <optimized out> ret = <optimized out> tid = <optimized out> ret = <optimized out> resultvar = <optimized out> resultvar = <optimized out> __arg3 = <optimized out> __arg2 = <optimized out> __arg1 = <optimized out> _a3 = <optimized out> _a2 = <optimized out> _a1 = <optimized out> __futex = <optimized out> resultvar = <optimized out> __arg3 = <optimized out> __arg2 = <optimized out> __arg1 = <optimized out> _a3 = <optimized out> _a2 = <optimized out> _a1 = <optimized out> __futex = <optimized out> __private = <optimized out> __oldval = <optimized out> result = <optimized out> #1 __pthread_kill_internal (signo=6, threadid=140425701996352) at ./nptl/pthread_kill.c:78 No locals. #2 __GI___pthread_kill (threadid=140425701996352, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 No locals. #3 0x00007fb7681a0476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 ret = <optimized out> #4 0x00007fb7681867f3 in __GI_abort () at ./stdlib/abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x100000000, sa_sigaction = 0x100000000}, sa_mask = {__val = {140425395047168, 140725986283888, 140425393986269, 140425394365984, 140425394130944, 140425394801736, 5734026312, 140725986283952, 140425394028321, 15624006419995803439, 94230961557227, 94230963279168, 94230963279576, 140425422497024, 13020282480951897856, 72}}, sa_flags = -619194838, sa_restorer = 0x0} sigs = {__val = {32, 13020282480951897856, 140725986284000, 94230961610857, 13546569962021497653, 14189927350396752214, 94230962920532, 0, 94230963279402, 140425394130944, 10, 38654707763, 12, 140425395047168, 32, 1438623432}} #5 0x000055b3dafd8f12 in qm_debug_check_frag (qm=0x7fb755bc1000, f=0x7fb7576ce500, file=0x7fb766123154 "tls: tls_init.c", line=323, efile=0x55b3db17d559 "core/mem/q_malloc.c", eline=511) at core/mem/q_malloc.c:129 p = 0x7fb755ca0b00 __func__ = "qm_debug_check_frag" #6 0x000055b3dafdd788 in qm_free (qmp=0x7fb755bc1000, p=0x7fb7576ce538, file=0x7fb766123154 "tls: tls_init.c", func=0x7fb766124990 <__func__.0> "ser_free", line=323, mname=0x7fb766123150 "tls") at core/mem/q_malloc.c:511 qm = 0x7fb755bc1000 f = 0x7fb7576ce500 size = 24 next = 0x7fb7576ce500 prev = 0x7fb7576ce3f8 __func__ = "qm_free" #7 0x000055b3dafe954e in qm_shm_free (qmp=0x7fb755bc1000, p=0x7fb7576ce538, file=0x7fb766123154 "tls: tls_init.c", func=0x7fb766124990 <__func__.0> "ser_free", line=323, mname=0x7fb766123150 "tls") at core/mem/q_malloc.c:1350 No locals. #8 0x00007fb7660db698 in ser_free (ptr=0x7fb7576ce538, fname=0x7fb765efa6e5 "../crypto/err/err_local.h", fline=88) at tls_init.c:323 __func__ = "ser_free" #9 0x00007fb765d2e907 in ERR_pop_to_mark () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #10 0x00007fb765d76a42 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #11 0x00007fb765d669f5 in EVP_PKEY_set_type_by_keymgmt () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #12 0x00007fb765d5ef9a in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #13 0x00007fb765d69973 in EVP_PKEY_generate () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #14 0x00007fb766029279 in ?? () from /lib/x86_64-linux-gnu/libssl.so.3 No symbol table info available. #15 0x00007fb76607a621 in ?? () from /lib/x86_64-linux-gnu/libssl.so.3 No symbol table info available. --Type <RET> for more, q to quit, c to continue without paging--c #16 0x00007fb7660687fd in ?? () from /lib/x86_64-linux-gnu/libssl.so.3 No symbol table info available. #17 0x00007fb766104216 in tls_accept (c=0x7fb7576db4e8, error=0x7ffd526c58a4) at tls_server.c:468 ret = 1382832224 ssl = 0x7fb75755bef0 cert = 0x7fb75742dbb0 tls_c = 0x7fb7574429a8 tls_log = 1712337076 __func__ = "tls_accept" pkey = 0x0 #18 0x00007fb76610f86d in tls_h_read_f (c=0x7fb7576db4e8, flags=0x7ffd526e5dac) at tls_server.c:1173 r = 0x7fb7576db610 bytes_free = 16383 bytes_read = 150 read_size = 16383 ssl_error = 0 ssl_read = 0 ssl = 0x7fb75755bef0 rd_buf = "\026\003\003\000\221\001\000\000\215\003\003b\347\222\177\213T\226\b\b\214\273\355\255[l\354\211\371rJ;<\033\356B\374y\024cg\352\067\000\000\020\300\060\300/\300(\300'\300,\300+\300$\300#\001\000\000T\000\000\000\022\000\020\000\000\rdr.teamsdr.uk\000\005\000\005\001\000\000\000\000\000\n\000\006\000\004\000\030\000\027\000\v\000\002\001\000\000\r\000\024\000\022\004\001\005\001\002\001\004\003\005\003\002\003\002\002\006\001\006\003\000#\000\000\000\027\000\000\377\001\000\001\000G\225 E\030j\223\313Hb\244@\271\323\030GQ\254\272\024\032z=H-\277\360\226\035qw\244\270(\004D\004\241\023\062\064\026\226\376\321\067\274\370\376?"... wr_buf = "\026\003\003\000E\002\000\000A\003\003OHu\016\240\363=\252\356\260#\221\a\310ò&\237\000:FɆ\351DOWNGRD\001\000\300\060\000\000\031\377\001\000\001\000\000\000\000\000\000\v\000\004\003\000\001\002\000#\000\000\000\027\000\000\026\003\003\020\006\v\000\020\002\000\017\377\000\005x0\202\005t0\202\004\\\240\003\002\001\002\002\022\004\062_\v\313\031\021 \240[\376N\227\346\310\004e\r0\r\006\t*\206H\206\367\r\001\001\v\005\000\060\062\061\v0\t\006\003U\004\006\023\002US1\026\060\024\006\003U\004\n\023\rLet's Encrypt1\v0\t\006\003U\004\003\023\002R30\036\027\r22070519555"... rd = {buf = 0x7ffd526c5a00 "\026\003\003", pos = 150, used = 150, size = 65536} wr = {buf = 0x7ffd526d5a00 "\026\003\003", pos = 0, used = 4096, size = 65536} tls_c = 0x7fb7574429a8 enc_rd_buf = 0x0 n = 0 flush_flags = 1 err_src = 0x7fb76612c9b0 "TLS read:" ip_buf = "172.16.51.200", '\000' <repeats 50 times> x = 0 tls_dbg = 0 __func__ = "tls_h_read_f" #19 0x000055b3daf819f3 in tcp_read_headers (c=0x7fb7576db4e8, read_flags=0x7ffd526e5dac) at core/tcp_read.c:441 bytes = 4 remaining = 0 p = 0x7fb75736b870 "2" r = 0x7fb7576db610 mc = 32695 body_len = 22326 mfline = 0x7fb755b9dadd <futex_release+29> "\211E\374\203}\374\002\017\224\300\017\266\300H\205\300t6H\213E\350H\203\354\bj" mtransid = {s = 0x55b3db16d884 "", len = 1439304448} __func__ = "tcp_read_headers" #20 0x000055b3daf8ac9d in tcp_read_req (con=0x7fb7576db4e8, bytes_read=0x7ffd526e5da8, read_flags=0x7ffd526e5dac) at core/tcp_read.c:1469 bytes = -1 total_bytes = 0 resp = 1 size = 154618822664 req = 0x7fb7576db610 dst = {send_sock = 0x1, to = {s = {sa_family = 2816, sa_data = "\312U\267\177\000\000\320\\nR\375\177\000"}, sin = {sin_family = 2816, sin_port = 21962, sin_addr = {s_addr = 32695}, sin_zero = "\320\\nR\375\177\000"}, sin6 = {sin6_family = 2816, sin6_port = 21962, sin6_flowinfo = 32695, sin6_addr = {__in6_u = {__u6_addr8 = "\320\\nR\375\177\000\000\030\000\000\000\000\000\000", __u6_addr16 = {23760, 21102, 32765, 0, 24, 0, 0, 0}, __u6_addr32 = {1382964432, 32765, 24, 0}}}, sin6_scope_id = 1382964400}, sas = {ss_family = 2816, __ss_padding = "\312U\267\177\000\000\320\\nR\375\177\000\000\030\000\000\000\000\000\000\000\260\\nR\001\000\000\000\000\v\312U\267\177\000\000\260\\nR\375\177\000\000\335ڹU\267\177\000\000\204\330\026۳U\000\000\000\v\312U\267\177\000\000\002\000\000\000\000\000\000\000\002\000\000\000\001\000\000\000\360\\nR\375\177\000\000!\177\272U\267\177\000\000\360]nR\375\177\000\000\024]nR\375\177\000", __ss_align = 17179869204}}, id = -619259776, send_flags = {f = 21939, blst_imask = 0}, proto = 110 'n', proto_pad0 = -11 '\365', proto_pad1 = 28435} c = 0 '\000' ret = 1438243549 __func__ = "tcp_read_req" #21 0x000055b3daf9072c in handle_io (fm=0x7fb766755bb8, events=1, idx=-1) at core/tcp_read.c:1780 ret = 8 n = 8 read_flags = RD_CONN_SHORT_READ con = 0x7fb7576db4e8 s = 12 resp = 140425703179696 t = 1467216201 ee = 0x0 __func__ = "handle_io" #22 0x000055b3daf7bd70 in io_wait_loop_epoll (h=0x55b3db270960 <io_w>, t=2, repeat=0) at core/io_wait.h:1070 n = 1 r = 0 fm = 0x7fb766755bb8 revents = 1 __func__ = "io_wait_loop_epoll" #23 0x000055b3daf93760 in tcp_receive_loop (unix_sock=36) at core/tcp_read.c:1976 __func__ = "tcp_receive_loop" #24 0x000055b3daf6fdde in tcp_init_children (woneinit=0x7ffd526e6198) at core/tcp_main.c:5236 r = 0 i = 7 reader_fd_1 = 36 pid = 0 si_desc = "tcp receiver (generic)\000\000\356\376\357ڳU\000\000panR\375\177\000\000\036\350\371\332\000\000\000\000\070\n\037f\000\000\000\000\313\307\025۳U\000\000\241\000nR\375\177\000\000\fj\f۳U\000\000\000\000\000\000\000\000\000\000ز\277U\267\177\000\000\036\000\000\000\000\000\000\000\020\316\363U\001\000\000\000`anR\375\177\000\000\036l\f۳U\000" si = 0x0 __func__ = "tcp_init_children" #25 0x000055b3dacbe65c in main_loop () at main.c:1851 i = 4 pid = 7714 si = 0x0 si_desc = "udp receiver child=3 sock=127.0.0.1:5050\000\060\066\060\000\000\000\000\003\000\000\000\036\000\000\000\000/a\230\356U\261\264X\307\036۳U\000\000\210\360\020۳U\000\000\000\000\000\000\000\000\000\000s\\\022۳U\000\000\036\000\000\000\000\000\000\000\260\305'h\267\177\000\000\060cnR\375\177\000\000zI\347ڳU\000" nrprocs = 4 woneinit = 1 __func__ = "main_loop" #26 0x000055b3dacc95b0 in main (argc=11, argv=0x7ffd526e68a8) at main.c:3085 cfg_stream = 0x55b3dc09c380 c = -1 r = 0 tmp = 0x7ffd526e7e37 "" tmp_len = 0 port = 0 proto = 0 ahost = 0x0 aport = 0 options = 0x55b3db112278 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 1456913526 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x7fb768491cee <_dl_runtime_resolve_xsave+142> p = 0x7ffd526e68a8 "\334}nR\375\177" st = {st_dev = 25, st_ino = 1712, st_nlink = 2, st_mode = 16892, st_uid = 9002, st_gid = 9002, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1659341338, tv_nsec = 499520451}, st_mtim = {tv_sec = 1659341338, tv_nsec = 499520451}, st_ctim = {tv_sec = 1659341338, tv_nsec = 499520451}, __glibc_reserved = {0, 0, 0}} tbuf = '\000' <repeats 64 times>, "\377\000\000\000\000\000\000\000\000\377", '\000' <repeats 18 times>, "\377", '\000' <repeats 19 times>, "`", '\000' <repeats 15 times>, "\001", '\000' <repeats 145 times>... option_index = 0 long_options = {{name = 0x55b3db1146b6 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x55b3db10f521 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x55b3db1146bb "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x55b3db1146c1 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x55b3db1146c7 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x55b3db1146d0 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x55b3db1146da "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x55b3db1146e4 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x55b3db1146ef "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x55b3db1146f8 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x55b3db114703 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x55b3db114709 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x55b3db114713 "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x55b3db11471a "all-errors", has_arg = 0, flag = 0x0, val = 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" (gdb) info locals tid = <optimized out> ret = 0 pd = 0x7fb76815b740 old_mask = {__val = {523986010119, 910533066753, 1, 140425395047168, 94230980435360, 0, 5677797456, 140425395047168, 140725986283600, 140425393986269, 94230963279192, 140425395047168, 94230963279402, 7970739754, 140725986283664, 140425394028321}} ret = <optimized out> pd = <optimized out> old_mask = <optimized out> ret = <optimized out> tid = <optimized out> ret = <optimized out> resultvar = <optimized out> resultvar = <optimized out> __arg3 = <optimized out> __arg2 = <optimized out> __arg1 = <optimized out> _a3 = <optimized out> _a2 = <optimized out> _a1 = <optimized out> __futex = <optimized out> resultvar = <optimized out> __arg3 = <optimized out> __arg2 = <optimized out> __arg1 = <optimized out> _a3 = <optimized out> _a2 = <optimized out> _a1 = <optimized out> __futex = <optimized out> __private = <optimized out> __oldval = <optimized out> result = <optimized out> (gdb) list 39 in ./nptl/pthread_kill.cq ``` #### Log Messages  ``` Aug 1 12:21:45 kam-test01 /usr/local/sbin/kamailio[25442]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Aug 1 12:21:47 kam-test01 kamailio: INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Aug 1 12:21:47 kam-test01 kamailio: INFO: <core> [core/tcp_main.c:5080]: init_tcp(): using epoll_lt as the io watch method (auto detected) Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_mod.c:399]: mod_init(): use OpenSSL version: 30000020 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_mod.c:401]: mod_init(): With ECDH-Support! Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_mod.c:404]: mod_init(): With Diffie Hellman Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: auth [auth_mod.c:345]: mod_init(): qop set, but nonce-count (nonce_count) support disabled Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: rr [rr_mod.c:188]: mod_init(): outbound module not available Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: db_text [dbt_lib.c:146]: dbt_cache_get_db(): using database at: /etc/kamailio/dbtext Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: WARNING: tls [tls_init.c:804]: tls_h_mod_init_f(): tls: openssl bug #1491 (crash/mem leaks on low memory) workaround disabled Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: <core> [main.c:3062]: main(): processes (at least): 30 - shm size: 134217728 - pkg size: 33554432 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 9 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: <core> [core/udp_server.c:207]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 9 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 10 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: <core> [core/udp_server.c:207]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 10 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 11 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: <core> [core/udp_server.c:207]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 11 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:328]: ksr_tls_fill_missing(): TLSs<default>: tls_method=20 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<default>: certificate='/etc/kamailio/livecert/fullchain.pem' Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<default>: ca_list='/etc/kamailio/livecert/chain.pem' Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<default>: ca_path='(null)' Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:361]: ksr_tls_fill_missing(): TLSs<default>: crl='(null)' Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:364]: ksr_tls_fill_missing(): TLSs<default>: require_certificate=0 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:372]: ksr_tls_fill_missing(): TLSs<default>: cipher_list='AES256-SHA' Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:379]: ksr_tls_fill_missing(): TLSs<default>: private_key='/etc/kamailio/livecert/privkey.pem' Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:382]: ksr_tls_fill_missing(): TLSs<default>: verify_certificate=0 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:386]: ksr_tls_fill_missing(): TLSs<default>: verify_depth=9 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:389]: ksr_tls_fill_missing(): TLSs<default>: verify_client=0 Aug 1 12:21:47 kam-test01 /usr/local/sbin/kamailio[25502]: NOTICE: tls [tls_domain.c:1144]: ksr_tls_fix_domain(): registered server_name callback handler for socket [:0], server_name='<default>' ... Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:750]: set_verification(): TLSs<default>: No client certificate required and no checks performed Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:328]: ksr_tls_fill_missing(): TLSc<default>: tls_method=18 Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSc<default>: certificate='/etc/kamailio/livecert/fullchain.pem' Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<default>: ca_list='/etc/kamailio/livecert/chain.pem' Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<default>: ca_path='(null)' Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:361]: ksr_tls_fill_missing(): TLSc<default>: crl='(null)' Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:364]: ksr_tls_fill_missing(): TLSc<default>: require_certificate=0 Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:372]: ksr_tls_fill_missing(): TLSc<default>: cipher_list='ECDHE-RSA-AES256-GCM-SHA384' Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:379]: ksr_tls_fill_missing(): TLSc<default>: private_key='/etc/kamailio/livecert/privkey.pem' Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:382]: ksr_tls_fill_missing(): TLSc<default>: verify_certificate=0 Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:386]: ksr_tls_fill_missing(): TLSc<default>: verify_depth=9 Aug 1 12:21:49 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:389]: ksr_tls_fill_missing(): TLSc<default>: verify_client=0 Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:753]: set_verification(): TLSc<default>: Server MAY present invalid certificate Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:328]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: tls_method=22 Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: certificate='/etc/kamailio/livecert/fullchain.pem' Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: ca_list='/etc/kamailio/livecert/chain.pem' Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: ca_path='(null)' Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:361]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: crl='(null)' Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:364]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: require_certificate=0 Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:372]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: cipher_list='ECDHE-RSA-AES256-GCM-SHA384' Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:379]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: private_key='/etc/kamailio/livecert/privkey.pem' Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:382]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: verify_certificate=0 Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:386]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: verify_depth=9 Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:389]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: verify_client=0 Aug 1 12:21:50 kam-test01 /usr/local/sbin/kamailio[25502]: NOTICE: tls [tls_domain.c:1144]: ksr_tls_fix_domain(): registered server_name callback handler for socket [172.16.51.200:5067], server_name='test2.test.com' ... Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:750]: set_verification(): TLSs<172.16.51.200:5067>: No client certificate required and no checks performed Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:328]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: tls_method=22 Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: certificate='/etc/kamailio/livecert/fullchain.pem' Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: ca_list='/etc/kamailio/livecert/chain.pem' Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: ca_path='(null)' Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:361]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: crl='(null)' Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:364]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: require_certificate=0 Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:372]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: cipher_list='ECDHE-RSA-AES256-GCM-SHA384' Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:379]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: private_key='/etc/kamailio/livecert/privkey.pem' Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:382]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: verify_certificate=0 Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:386]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: verify_depth=9 Aug 1 12:21:51 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:389]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: verify_client=0 Aug 1 12:21:52 kam-test01 /usr/local/sbin/kamailio[25502]: NOTICE: tls [tls_domain.c:1144]: ksr_tls_fix_domain(): registered server_name callback handler for socket [172.16.51.200:5067], server_name='test.test.com' ... Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:750]: set_verification(): TLSs<172.16.51.200:5067>: No client certificate required and no checks performed Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:328]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: tls_method=22 Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: certificate='/etc/kamailio/livecert/fullchain.pem' Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: ca_list='/etc/kamailio/livecert/chain.pem' Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: ca_path='(null)' Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:361]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: crl='(null)' Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:364]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: require_certificate=0 Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:372]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: cipher_list='ECDHE-RSA-AES256-GCM-SHA384' Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:379]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: private_key='/etc/kamailio/livecert/privkey.pem' Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:382]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: verify_certificate=0 Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:386]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: verify_depth=9 Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:389]: ksr_tls_fill_missing(): TLSs<172.16.51.200:5067>: verify_client=0 Aug 1 12:21:53 kam-test01 /usr/local/sbin/kamailio[25502]: NOTICE: tls [tls_domain.c:1144]: ksr_tls_fix_domain(): registered server_name callback handler for socket [172.16.51.200:5067], server_name='test3.test.com' ... Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:750]: set_verification(): TLSs<172.16.51.200:5067>: No client certificate required and no checks performed Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:328]: ksr_tls_fill_missing(): TLSc<172.16.51.200:5067>: tls_method=18 Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:340]: ksr_tls_fill_missing(): TLSc<172.16.51.200:5067>: certificate='/etc/kamailio/livecert/fullchain.pem' Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<172.16.51.200:5067>: ca_list='/etc/kamailio/livecert/chain.pem' Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<172.16.51.200:5067>: ca_path='(null)' Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:361]: ksr_tls_fill_missing(): TLSc<172.16.51.200:5067>: crl='(null)' Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:364]: ksr_tls_fill_missing(): TLSc<172.16.51.200:5067>: require_certificate=0 Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:372]: ksr_tls_fill_missing(): TLSc<172.16.51.200:5067>: cipher_list='ECDHE-RSA-AES256-GCM-SHA384' Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:379]: ksr_tls_fill_missing(): TLSc<172.16.51.200:5067>: private_key='/etc/kamailio/livecert/privkey.pem' Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:382]: ksr_tls_fill_missing(): TLSc<172.16.51.200:5067>: verify_certificate=0 Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:386]: ksr_tls_fill_missing(): TLSc<172.16.51.200:5067>: verify_depth=9 Aug 1 12:21:54 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:389]: ksr_tls_fill_missing(): TLSc<172.16.51.200:5067>: verify_client=0 Aug 1 12:21:56 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: tls [tls_domain.c:753]: set_verification(): TLSc<172.16.51.200:5067>: Server MAY present invalid certificate Aug 1 12:21:56 kam-test01 /usr/local/sbin/kamailio[25504]: INFO: rtpengine [rtpengine.c:2929]: rtpp_test(): rtpengine instance <udp:127.0.0.1:2223> found, support for it enabled Aug 1 12:21:56 kam-test01 /usr/local/sbin/kamailio[25520]: INFO: jsonrpcs [jsonrpcs_sock.c:443]: jsonrpc_dgram_process(): a new child 0/25520 Aug 1 12:21:56 kam-test01 /usr/local/sbin/kamailio[25523]: INFO: ctl [io_listener.c:213]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) Aug 1 12:21:57 kam-test01 /usr/local/sbin/kamailio[25525]: ERROR: <script>: 758:No dispatcher sets up yet Aug 1 12:21:57 kam-test01 /usr/local/sbin/kamailio[25525]: ERROR: <script>: 758:No dispatcher sets up yet Aug 1 12:21:57 kam-test01 /usr/local/sbin/kamailio[25525]: WARNING: <script>: 548:[LOCATION] Location not found rc: -1 sip:lPBKm2s70BBd6u@sipuat.voicesimplified.com;transport=TLS Aug 1 12:21:57 kam-test01 /usr/local/sbin/kamailio[25525]: ERROR: <script>: 758:No dispatcher sets up yet Aug 1 12:21:59 kam-test01 /usr/local/sbin/kamailio[25532]: ERROR: <core> [core/tcp_main.c:4672]: tcpconn_main_timeout(): connect 185.29.208.21:5061 failed (timeout) Aug 1 12:22:06 kam-test01 /usr/local/sbin/kamailio[25508]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:06 kam-test01 /usr/local/sbin/kamailio[25510]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:06 kam-test01 /usr/local/sbin/kamailio[25511]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:06 kam-test01 /usr/local/sbin/kamailio[25508]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:06 kam-test01 /usr/local/sbin/kamailio[25504]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:06 kam-test01 /usr/local/sbin/kamailio[25505]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:06 kam-test01 /usr/local/sbin/kamailio[25504]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:07 kam-test01 /usr/local/sbin/kamailio[25506]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:07 kam-test01 /usr/local/sbin/kamailio[25505]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:07 kam-test01 /usr/local/sbin/kamailio[25506]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:07 kam-test01 /usr/local/sbin/kamailio[25507]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:07 kam-test01 /usr/local/sbin/kamailio[25506]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:22:07 kam-test01 /usr/local/sbin/kamailio[25506]: NOTICE: <script>: Destination up: sip:redacted Aug 1 12:24:48 kam-test01 /usr/local/sbin/kamailio[25525]: INFO: <script>: R-URI Alias Found and processed Aug 1 12:24:48 kam-test01 /usr/local/sbin/kamailio[25510]: INFO: <script>: R-URI Alias Found and processed Aug 1 12:26:06 kam-test01 /usr/local/sbin/kamailio[25513]: WARNING: tm [t_reply.c:1677]: t_retransmit_reply(): no resolved dst to retransmit Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25526]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f7a8a860d80), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25532]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 36 Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25502]: ALERT: <core> [main.c:776]: handle_sigs(): child process 25526 exited by a signal 11 Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25502]: ALERT: <core> [main.c:779]: handle_sigs(): core was generated Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25502]: INFO: <core> [main.c:801]: handle_sigs(): terminating due to SIGCHLD Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25532]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25513]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25531]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25522]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25521]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25525]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25520]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25514]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25529]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25511]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25515]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25509]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25519]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25516]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25517]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25512]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25510]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25506]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25504]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25524]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25518]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25523]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25508]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25528]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25530]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25505]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25507]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received Aug 1 12:27:17 kam-test01 /usr/local/sbin/kamailio[25527]: INFO: <core> [main.c:856]: sig_usr(): signal 15 received ``` ### Additional Information Tested against kamailio 5.6 and devel branches with a distclean between builds ``` (paste your output here) ``` * **Operating System**:  ``` No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.1 LTS Release: 22.04 Codename: jammy Linux kam-test01 5.15.0-1014-azure #17-Ubuntu SMP Thu Jun 23 19:04:16 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3205 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3205(a)github.com>

7 21

[kamailio/kamailio] Usrloc keepalive: Not sending OPTIONS to UDP endpoints- 5.8.0 and 5.8.1 (Issue #3844)
by Luke Escudé 17 Oct '24

17 Oct '24

Running compiled Kamailio 5.8.1 (previously 5.8.0) on Debian 12 64-bit We're seeing an issue with UDP endpoints (this issue does not happen with TCP and TLS) where usrloc will not send OPTIONS packet keepalives. Here are all of our usrloc parameters: modparam("usrloc", "db_mode", 0) modparam("usrloc", "ka_domain", "SIPDOMAIN") #-- SIPDOMAIN is a fqdn modparam("usrloc", "ka_from", "sip:proxy-ping@SIPDOMAIN") modparam("usrloc", "ka_mode", 1) modparam("usrloc", "timer_interval", 20) #-- How often to qualify endpoints and clean mem tables? modparam("usrloc", "timer_procs", 4) modparam("usrloc", "ka_randomize", 10) modparam("usrloc", "use_domain", 0) modparam("usrloc", "server_id_filter", 1) modparam("usrloc", "ka_filter", 0) modparam("usrloc", "ka_timeout", 60) #-- How quickly to expire a contact if it does not reply to keepalive? modparam("usrloc", "matching_mode", 0) modparam("usrloc", "handle_lost_tcp", 1) modparam("usrloc", "close_expired_tcp", 1) modparam("usrloc", "desc_time_order", 1) modparam("usrloc", "hash_size", 14) It seems usrloc is not actually using timer_interval at all for UDP devices. However, it does seem to be sending OPTIONS every 20 seconds on TCP/TLS. (this is confirmed via packet capture on a SIP phone). -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3844 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3844(a)github.com>

4 9

[kamailio/kamailio] kazoo: 'amqp_set_initialize_ssl_library' is deprecated (Issue #3466)
by sergey-safarov 08 Oct '24

08 Oct '24

From the build log ``` CC (gcc) [M kazoo.so] kazoo.o CC (gcc) [M kazoo.so] kz_amqp.o kz_amqp.c: In function 'kz_amqp_connection_open_ssl': kz_amqp.c:857:17: warning: 'amqp_set_initialize_ssl_library' is deprecated [-Wdeprecated-declarations] 857 | amqp_set_initialize_ssl_library(1); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from kz_amqp.c:37: /usr/include/rabbitmq-c/ssl_socket.h:233:16: note: declared here 233 | void AMQP_CALL amqp_set_initialize_ssl_library(amqp_boolean_t do_initialize); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC (gcc) [M kazoo.so] kz_fixup.o CC (gcc) [M kazoo.so] kz_hash.o ``` Functions description in the header file https://github.com/alanxz/rabbitmq-c/blob/v0.13.0/include/rabbitmq-c/ssl_so… ``` /** * Sets whether rabbitmq-c will initialize OpenSSL. * * \deprecated Since v0.13.0 this is a no-op. OpenSSL automatically manages * library initialization and uninitialization. * * OpenSSL requires a one-time initialization across a whole program, this sets * whether or not rabbitmq-c will initialize the SSL library when the first call * to amqp_ssl_socket_new() is made. You should call this function with * do_init = 0 if the underlying SSL library is initialized somewhere else * the program. * * Failing to initialize or double initialization of the SSL library will * result in undefined behavior * * By default rabbitmq-c will initialize the underlying SSL library. * * NOTE: calling this function after the first socket has been opened with * amqp_open_socket() will not have any effect. * * \param [in] do_initialize If 0 rabbitmq-c will not initialize the SSL * library, otherwise rabbitmq-c will initialize the * SSL library * * \since v0.4.0 */ ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3466 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3466(a)github.com>

3 4

[kamailio/kamailio] The tm.cancel function does not generate a “tm:local-request” event. (Issue #3831)
by JuanPascual2 30 Sep '24

30 Sep '24

Hello The tm.t_uac_start function generates a “tm:local-request” event. But the tm.cancel function doesn't generete “tm:local-request” event. Is it possible to activate a parameter in the TM or TMX module to generate the event? Thanks Juan -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3831 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3831(a)github.com>

4 12

[kamailio/kamailio] TM crash when relaying reply, in context of unreachable rtpengine (Issue #3297)
by Alex Balashov 22 Sep '24

22 Sep '24

When relaying this `200 OK` repeatedly with calls to `rtpengine_answer()` failing because all RTPEngines in a set are unreachable... ``` Dec 8 06:24:38 gw kamailio[4823]: ERROR: rtpengine [rtpengine.c:2960]: select_rtpp_node(): rtpengine failed to select new for calllen=36 callid=8279a4ea-151e-48de-a23c-5840104126de ``` ``` SIP/2.0 200 OK v:SIP/2.0/UDP 10.150.20.20;branch=z9hG4bK03e.e4da444e627bb575ef4f46151729a1fa.0,SIP/2.0/UDP 10.151.20.108;received=10.151.20.108;rport=5060;branch=z9hG4bKKQyrBKpp04X0K Record-Route:<sip:10.150.20.20;lr;ftag=emHm2apy95jFe;rtp_relay=1;rtp_group=0> f:"14045551212"<sip:14045551212@10.151.20.108>;tag=emHm2apy95jFe t:<sip:16782001111@internal.evaristesys.com>;tag=tHQt0rDcF7UHK i:8279a4ea-151e-48de-a23c-5840104126de CSeq:60686471 INVITE m:<sip:16782001111@10.160.10.55:5060;transport=udp> User-Agent:VoiceAppServer Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,REFER,NOTIFY k:path,replaces u:talk,hold,conference,refer c:application/sdp Content-Disposition:session l:257 v=0 o=DM 1670428117 1670428118 IN IP4 10.160.10.55 s=DM c=IN IP4 10.160.10.55 t=0 0 m=audio 52418 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=rtcp:52419 IN IP4 10.160.10.55 ``` Repeat INVITEs eventually result in a crash. This backtrace is taken from a different server but identical scenario: ``` #0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40, reply=0x7f4afe40df70) at t_reply.c:1285 1285 && !(inv_through && Trans->uac[branch].last_received<300)) { Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.192.el6.x86_64 jansson-2.11-1.el6.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-57.el6.x86_64 libcom_err-1.41.12-22.el6.x86_64 libev-4.03-3.el6.x86_64 libselinux-2.0.94-7.el6.x86_64 libunistring-0.9.3-5.el6.x86_64 openssl-1.0.1e-48.el6_8.3.x86_64 sqlite-3.6.20-1.el6_7.2.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) where #0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40, reply=0x7f4afe40df70) at t_reply.c:1285 #1 0x00007f4afd73ab7d in relay_reply (t=0x7f4aee56ba80, p_msg=0x7f4afe40df70, branch=0, msg_status=200, cancel_data=0x7ffd8b8bbe40, do_put_on_wait=1) at t_reply.c:1821 #2 0x00007f4afd740c38 in reply_received (p_msg=0x7f4afe40df70) at t_reply.c:2558 #3 0x00000000004b5d6a in do_forward_reply (msg=0x7f4afe40df70, mode=0) at core/forward.c:747 #4 0x00000000004b78c9 in forward_reply (msg=0x7f4afe40df70) at core/forward.c:852 #5 0x000000000054982b in receive_msg ( buf=0xb27700 "SIP/2.0 200 OK\r\nv:SIP/2.0/UDP xxx;branch=z9hG4bK9915.dcfe6d03cb21e6c94a6705adb095c566.0,SIP/2.0/UDP xxx;received=xxx;rport=5060;branch=z9hG4bKZmZp0NZv3FvQB\r\nRecord-Rout"..., len=984, rcv_info=0x7ffd8b8bc6c0) at core/receive.c:434 #6 0x00000000006658ca in udp_rcv_loop () at core/udp_server.c:541 #7 0x000000000042500f in main_loop () at main.c:1655 #8 0x000000000042c5bb in main (argc=11, argv=0x7ffd8b8bcc88) at main.c:2696 ``` Looks like in the crash frame, `Trans->uac` is `NULL`: ``` (gdb) frame 0 #0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40, reply=0x7f4afe40df70) at t_reply.c:1285 1285 && !(inv_through && Trans->uac[branch].last_received<300)) { (gdb) print Trans->uac $1 = (struct ua_client *) 0x0 ``` I have seen this crash from time to time, though it is infrequent. It always seems to occur when there are problems reaching RTPEngine in a timely fashion. This is on Kamailio 5.2.4:de9a03, which I know has long fallen off the back of the maintenance train. However, line 1386 of `t_reply.c` in `master:HEAD` shows that the code is no different now: https://github.com/kamailio/kamailio/blob/master/src/modules/tm/t_reply.c#L… Of course, it's possible that something upstream has changed so as to prevent this state. Otherwise, I suppose a null pointer safety check for `Trans->uac` is recommended. I'd be happy to submit a patch, just wasn't sure if the feeling was more that this should be resolved higher up the call stack. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3297 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3297(a)github.com>

2 3

[kamailio/kamailio] core/tcp_main: Match protocol when lookup tcp/tls connections (PR #3810)
by Xenofon Karamanos 21 Sep '24

21 Sep '24

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [x] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue [reported in lists](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.k… #### Description  This PR aims to fix a bug/security issue where data that was supposed to be encrypted and transferred through TLS, were transferred instead with TCP protocol. More information and how to replicate can be found in the above [issue](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.k… in list. This PR suggests using also the protocol to match if a TCP connection exists, and when doing connection lookups, otherwise, it might return a wrong connection, ie a TCP one when we are asking for a TLS one (a case when source ip/port and dest IP are same but dest port is set 0 (wildcard) ). `tcpconn_get` was left unchanged due to being used by some modules and not wanting to break them. Please advise whether it should be beneficial to also change it. In some cases like, `tcpconn_add_alias` and `tcpconn_get` we used the `PROTO_NONE` which preserves the original behavior. `tcpconn_add_alias` we do have the protocol available, should it be also used? `tcpconn_get` does not have the protocol available unless we pass it as an argument. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3810 -- Commit Summary -- * tcp_main: Add protocol argument for searching tcp/tls connections * tcp_main: Add proto argument to tcpconn_exists function * tcp_main: Update comment docs * core/forward: Match protocol when forwarding * tcp_main: Match wss protocol -- File Changes -- M src/core/forward.h (3) M src/core/tcp_conn.h (3) M src/core/tcp_main.c (43) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3810.patch https://github.com/kamailio/kamailio/pull/3810.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3810 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3810(a)github.com>

5 10

[kamailio/kamailio] During de-registration procedure, clean-up is not happening if contact has * value (Issue #3848)
by deepak-git-account 24 Aug '24

24 Aug '24

### Description If Deregistration contains * in a contact field as described in RFC-3261, then the Kamailio is not cleaning the in-memory and database record. And the next iteration is not working correctly. Use of the "*" Contact header field value allows a registering UA to remove all bindings associated with an address-of-record without knowing their precise values.  Step:1 REGISTER USER UE-A Step:2: Wait for the certain duration Step:3: De-REGISTER USER UE-A (Contact header is using *) Step:4: Repeat from the step-1 After step:3, clean-up is not happening. Record can be seen in SQL. Note: If de-register contains specific CONTACT header, then cleanup is happening. ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: DEBUG: <script>: Contact headervalue: * May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=25 a=63 n=assign May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=26 a=26 n=xlog May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: DEBUG: <script>: Full URI from sip:49404965200004@open-ims.test: sip:49404965200004@open-ims.test May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=33 a=63 n=assign May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=34 a=63 n=assign May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=36 a=63 n=assign May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=37 a=26 n=xlog May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=38 a=63 n=assign May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=39 a=26 n=xlog May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=46 a=16 n=if May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=43 a=26 n=xlog May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=54 a=16 n=if May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=46 a=25 n=is_present_hf May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=47 a=26 n=xlog May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=50 a=25 n=append_hf May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=54 a=26 n=xlog May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=55 a=25 n=pcscf_save_pending May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: ims_registrar_pcscf [save.c:318]: save_pending(): No contact headers May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: DEBUG: ims_registrar_pcscf [save.c:492]: save_pending(): Error saving pending contact May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=67 a=16 n=if May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=65 a=63 n=assign May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[] c=[] l=0 a=12 n=seturi May 13 19:47:22 openims-tvmcfg-node-focal pcscf/pcscf[35816]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[REGISTER] c=[/usr/local/etc/kamailio/pcscf/route/register.cfg] l=71 a=26 n=xlog ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` kamailio -v version: kamailio 5.7.5 (x86_64/linux) 58499a-dirty flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 58499a -dirty compiled on 11:23:55 May 8 2024 with gcc 9.4.0 ``` * **Operating System**:  ``` lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.6 LTS Release: 20.04 Codename: focal ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3848 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3848(a)github.com>

5 9

[kamailio/kamailio] Hello, I would like to confirm if our SMS module supports sending long SMS messages ？ (Issue #3822)
by Helloworld1668 13 Aug '24

13 Aug '24

### Description  Hello, when I was testing the SMSC SMS business, I found that the SMS could not be forwarded by the SMSC when the characters were too long, approximately 117 characters. The issue was traced back to the smsops module, which has a limit on the length of the SMS, but it seems that it does not handle SMS segmentation. The error message returned is as follows. Could you please provide some suggestions and help? ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages ``` 2024-04-24T05:59:01.837950514Z 3(24) ERROR: <script>: SMS for "" (Valid: 0 ) 2024-04-24T05:59:14.466167796Z 2(23) ERROR: <script>: 3GPP-SMS: MESSAGE (sip:+8618107550088@ims.mnc011.mcc460.3gppnetwork.org (172.22.0.20:6060) to tel:+8613800138000, bnecb4LQJ(a)10.46.2.1) 2024-04-24T05:59:14.466173859Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length! 2024-04-24T05:59:14.466175929Z 2(23) ERROR: smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! 2024-04-24T05:59:14.466191554Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length! 2024-04-24T05:59:14.466194545Z 2(23) ERROR: smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! 2024-04-24T05:59:14.466196517Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length! 2024-04-24T05:59:14.466198406Z 2(23) ERROR: smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! 2024-04-24T05:59:14.466200311Z 2(23) ERROR: <script>: SMS for "" (Valid: ) 2024-04-24T05:59:14.466255812Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length! 2024-04-24T05:59:14.466276249Z 2(23) ERROR: smsops [smsops_impl.c:1903]: isRPDATA(): Error getting/decoding RP-Data from request! ``` #### SIP Traffic  ``` ``` ![image](https://github.com/kamailio/kamailio/assets/152272255/808e65ce-9763-4056-9924-77122f6d9c25) ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 4fb8ac -dirty compiled on 03:11:49 Apr 24 2024 with gcc 9.4.0 ``` version: kamailio 5.9.0-dev0 (x86_64/linux) 4fb8ac-dirty flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB ``` * **Operating System**:  ``` Linux sder 4.15.0-128-generic #131-Ubuntu SMP Wed Dec 9 06:57:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3822 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3822(a)github.com>

3 5

[kamailio/kamailio] Mem leak in smsops which leads to the udp receiver process leak memory continuously (Issue #3833)
by paresh-panda 02 Aug '24

02 Aug '24

Hi, I am using Kamailio 5.8.1 ( ubuntu 22.04 Jammy 64 Bit),. Below are the observations. I am running a load of 500 3GPP IMS SMS which kamailio decodes and sends to another application over Rabbit MQ (Kazoo Module). **-m 512 -M 256** , using 512 MB Shared memory and 256MB Package Memory. When the load for 20 mins the available Memory drops from **80% to 25%** And I see below error logs > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mem/q_malloc.c:324]: qm_find_free(): qm_find_free(0x7ff912e21010, 192); Free fragment not found! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mem/q_malloc.c:463]: qm_malloc(): qm_malloc(0x7ff912e21010, 192) called from smsops: smsops_impl.c: decode_3gpp_sms(813), module: smsops; Free fragment not found! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mem/q_malloc.c:324]: qm_find_free(): qm_find_free(0x7ff912e21010, 192); Free fragment not found! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mem/q_malloc.c:463]: qm_malloc(): qm_malloc(0x7ff912e21010, 192) called from smsops: smsops_impl.c: decode_3gpp_sms(813), module: smsops; Free fragment not found! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/pvapi.c:1136]: pv_parse_format(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/sr_module.c:1318]: fix_param(): bad PVE format: "PRD-IR92/11 term-Motorola/XT2205-1-T2STS33.105-51-11-1-2-2 device-type/smart-phone" > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mod_fix.c:601]: fixup_spve_null(): Cannot convert function parameter 1 to spve > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): runtime fixup failed for jansson_set param 3 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:539 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/sr_module.c:1208]: fix_param(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mod_fix.c:601]: fixup_spve_null(): Cannot convert function parameter 1 to spve > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): runtime fixup failed for jansson_set param 3 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:540 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/sr_module.c:1208]: fix_param(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mod_fix.c:601]: fixup_spve_null(): Cannot convert function parameter 1 to spve > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): runtime fixup failed for jansson_set param 3 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:541 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/rvalue.c:1321]: rval_get_str(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): failed to convert RVE to string > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:542 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/rvalue.c:1321]: rval_get_str(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): failed to convert RVE to string > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:543 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/rvalue.c:1321]: rval_get_str(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): failed to convert RVE to string > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:555 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/rvalue.c:1321]: rval_get_str(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): failed to convert RVE to string > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:556 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/rvalue.c:1321]: rval_get_str(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1171]: do_action(): failed to convert RVE to string > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:559 > I am attaching the configuration for reference. Help on this is much appreciated [configfiles.tar.gz](https://github.com/kamailio/kamailio/files/15148792/con… , I am looking into this issue for quite a long time. Thank you! Regards Paresh -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3833 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3833(a)github.com>

5 7

[kamailio/kamailio] Uint fixes (PR #3828)
by Tyler Moore 01 Aug '24

01 Aug '24

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description Adding support for converting unsigned integers from database tables into kamailio pseudo variables usable in the routing config. This is quite useful when pulling `int unsigned` fields from a database, in modules that support "extra fields" in their module parameters. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3828 -- Commit Summary -- * permissions: fixup uint support in address table reload * htable: add uint support when packing an htable * lib/srdb1: add uint support for db->pv conversions -- File Changes -- M src/lib/srdb1/db_ut.c (4) M src/modules/htable/ht_db.c (6) M src/modules/permissions/address.c (35) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3828.patch https://github.com/kamailio/kamailio/pull/3828.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3828 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3828(a)github.com>

4 9

[kamailio/kamailio] t_uac_send parser does not like exclamation or other non alphabetic characters in Contact header (Issue #3682)
by xaled1 24 Jul '24

24 Jul '24

Hi there is an issue with the SIP parser for the t_uac_send function https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.f.t_uac_send If I call this function for example: t_uac_send("INVITE", "sip:test@123.123.123.123:5060", "", "" ,"Content-Type: text/plain\r\nContact: <sip:85951b3d-096c-95d6-5f05-4f38095aca9f@172.17.64.120:5060;transport=tcp>;+u.sip!devicename.ccm.cisco.com=\"SEP5486BC7F2BBC\"", "Testbody") Then the resulting request is broken - it's probably due to a character (exclamation mark?) in the Contact header.... I tested it with a call from kemi, but it probably also occurs when you run it with a normal kamailio -script tests -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3682 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3682(a)github.com>

3 4

[kamailio/kamailio] Warnings emitted when calling functions from dialplan module (Issue #3851)
by Ben Kaufman 22 Jul '24

22 Jul '24

### Description Calling functions from the `dialplan` module in 5.8 (`dp_translate()`, `dp_match()`) results in the following line being logged: ``` WARNING: <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) ``` Is this a functional problem, or just a case of overly aggressive logging? ### Troubleshooting #### Reproduction Reproducible with the following kamailio config: ``` #!KAMAILIO loadmodule "pv" loadmodule "db_sqlite" loadmodule "xlog" loadmodule "dialplan" disable_tcp = true force_rport = true !!define DBFILE /etc/kamailio/kamailio.sqlite modparamx("db_sqlite","db_set_readonly", "$def(DBFILE)") modparamx("dialplan","db_url", "sqlite:///$def(DBFILE)") modparam("dialplan", "attrs_pvar", "$avp(dp_attrs)") request_route { if ( $rm == "ACK" ) { exit; } xinfo("$ci New request\n"); dp_match("1", "$rU"); exit; } ``` The warning log is issued in 5.8 but not 5.7. Reproduced by sending a request with SIPp: ``` sipp -sn uac -m 1 -s 15554445555 localhost ``` ### Possible Solutions Not sure if this is just a case of logging being overly aggressive, or an issue with the module's memory management. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.1 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ``` Tested using docker `debian:12-slim` using the official packages from `http://deb.kamailio.org/kamailio58` * **Operating System**: Docker debian:12-slim, but also observed in Alpine Linux/ -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3851 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3851(a)github.com>

6 13

[kamailio/kamailio] Dialog DMQ sync: Timer needs fixing, firing on wrong node! (Issue #3656)
by Benoît Panizzon 17 Jul '24

17 Jul '24

Situation: Two Kamailio nodes syncing dialog profiles via DMQ Observation: When a dialog timeout is encountered, about half of the time, the timeout is triggered on the peer node not handling the dialog preventing the call to be correctly terminated and also leaving entries in the dialog database which never get deleted. https://kamailio.org/docs/modules/5.7.x/modules/dialog.html#dialog.p.enable… Makes clear, that only the node which is handling the dialog in question, can make changes not related to the dialog profiles. So when a dialog times out, it is this node which has to trigger the timeout, not any other one. When looking at the source code, it is clear, that the 'lifetime' is transmitted via DMQ dialog message to the peer nodes, which in turn arm a timer. So it is obvious, this time will trigger, sometimes before the instance handling the dialog itself triggers that timer. With some assistance of @oej I found a way to alter the JSON payload to extend the lifetime on the peer nodes: ``` route[DMQ_CAPTURE] { if(is_method("KDMQ")) { if(has_body("application/json") && $fU == 'dialog') { if (jansson_get("lifetime", $rb, "$var(lifetime)")) { $var(new_lifetime) = $var(lifetime) + 60; # Add 60 seconds on DMQ peer to make sure it expires AFTER main node. $var(newrb) = $rb; jansson_set("integer", "lifetime", $var(new_lifetime), "$var(newrb)"); set_body("$var(newrb)","application/json"); msg_apply_changes(); } } dmq_handle_message(); exit; } } ``` Testing with this config fixed the issue of the timeout firing on a peer node instead of the node handling the dialog. Issue is present in 5.5, 5.6 and after looking at the code, I assume also on 5.7 -Benoît -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3656 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3656(a)github.com>

6 15

[kamailio/kamailio] Debian package build fails for Kamailio 5.7.4 (Issue #3722)
by Alexander Bakker 15 Jul '24

15 Jul '24

### Description The Debian package build fails for Kamailio 5.7.4 because it can't find static libssl. This happens because ``LIBSSL_STATIC_SRCPATH`` is set to the wrong location in the rules file. ### Troubleshooting #### Reproduction 1. Run ``ln -s pkg/kamailio/deb/bookworm debian`` 2. Run ``make deb`` #### Output ``` gcc -shared -g -m64 -Wl,-O2 -Wl,-E -Wl,-z,relro -pthread -rdynamic "-ldl" -Wl,-Bsymbolic-functions tls_bio.o tls_cfg.o tls_config.o tls_ct_wrq.o tls_domain.o tls_dump_vf.o tls_init.o tls_locking.o tls_map.o tls_rand.o tls_rpc.o tls_select.o tls_server.o tls_util.o tls_verify.o tlsa_mod.o -lm /usr/lib64/libssl.a /usr/lib64/libcrypto.a -o tlsa.so /usr/bin/ld: cannot find /usr/lib64/libssl.a: No such file or directory /usr/bin/ld: cannot find /usr/lib64/libcrypto.a: No such file or directory collect2: error: ld returned 1 exit status make[5]: *** [../../Makefile.rules:191: tlsa.so] Error 1 ``` ### Possible Solutions An extremely hacky workaround is to patch the rules file to point ``LIBSSL_STATIC_SRCPATH`` to the right location: ``` sed -i -e "/LIBSSL_STATIC_SRCPATH/a export\\ LIBSSL_STATIC_SRCPATH=\\/usr\\/lib\\/$(uname -m)-linux-gnu" pkg/kamailio/deb/bookworm/rules ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ``` * **Operating System**: ``` Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm ``` ``` Linux 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3722 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3722(a)github.com>

3 10

[kamailio/kamailio] No CDR is written on failover (Issue #3254)
by Earn330 15 Jul '24

15 Jul '24

Hi, I think there is an issue with writing CDRs on failover scenarios. I have two servers with Kamailio. Both server running Debian 11 (bulleye) and latest Kamailio 5.6.1 from git. I'm using DMQ to sync dialogs and htable between these servers, so both servers have the same knowledge of dialog state. Both Kamailio uses nobind option, so I can switch a VIP from one server to the other one. This is managed with keepalived. Switching the VIP from one server the other one works fine an while a call is running I can switch the VIP. I can see that the BYE Message is handled OK after I made a switch. I can see that acc is triggered but what is missing is acc_cdr in this case. I'm using htable to fill all necessary variables to complete the CDR an I can see that all values are synced correctly. The acc_cdr is created fine if there is no failover so i think it can't be an configuration issue. Both server holds the same Kamailio configuration except the IP. `version: kamailio 5.6.1 (x86_64/linux) bfc5c2-dirty flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: bfc5c2 -dirty compiled with gcc 10.2.1` `root@voip-lab-proxy01:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye` `root@voip-lab-proxy01:~# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 38 bits physical, 48 bits virtual CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 23 Model name: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz Stepping: 10 CPU MHz: 2500.088 BogoMIPS: 5000.17 Virtualization: VT-x Hypervisor vendor: KVM Virtualization type: full L1d cache: 128 KiB L1i cache: 128 KiB L2 cache: 16 MiB L3 cache: 16 MiB NUMA node0 CPU(s): 0-3 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Mitigation; PTE Inversion; VMX EPT disabled Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown Vulnerability Meltdown: Mitigation; PTI Vulnerability Mmio stale data: Unknown: No mitigations Vulnerability Retbleed: Not affected Vulnerability Spec store bypass: Vulnerable Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni vmx ssse3 cx16 pdcm sse4_1 x2apic tsc_deadline_timer xsave hypervisor lahf_lm cpuid_fault pti tpr_shadow vnmi flexpriority vpid tsc_adjust arat arch_capabilit ies` If you need more information, please let me know. As I'm running this on a test system I can reproduce the issue at any time. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3254 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3254(a)github.com>

5 9

[kamailio/kamailio] ims_registrar_scscf: cannot build on Fedora 40 (Issue #3855)
by sergey-safarov 12 Jul '24

12 Jul '24

### Description "ims_registrar_scscf" cannot be compiled on Fedora 40 dist. ``` CC (gcc) [M ims_registrar_scscf.so] reply.o CC (gcc) [M ims_registrar_scscf.so] rerrno.o CC (gcc) [M ims_registrar_scscf.so] save.o CC (gcc) [M ims_registrar_scscf.so] server_assignment.o CC (gcc) [M ims_registrar_scscf.so] sip_msg.o CC (gcc) [M ims_registrar_scscf.so] stats.o CC (gcc) [M ims_registrar_scscf.so] userdata_parser.o userdata_parser.c: In function ‘ifc_tDefaultHandling2char’: userdata_parser.c:126:13: error: implicit declaration of function ‘strtol’; did you mean ‘strtok’? [-Wimplicit-function-declaration] 126 | r = strtol((char *)x, (char **)NULL, 10); | ^~~~~~ | strtok userdata_parser.c: In function ‘parse_spt_extension’: userdata_parser.c:411:32: error: implicit declaration of function ‘atoi’ [-Wimplicit-function-declaration] 411 | switch(atoi((char *)x)) { | ^~~~ make[2]: *** [../../Makefile.rules:100: userdata_parser.o] Error 1 make[1]: *** [Makefile:508: modules] Error 1 make[1]: Leaving directory '/root/rpmbuild/BUILD/kamailio-5.8.1/src' make: *** [Makefile:34: every-module] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.tyeQgK (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.tyeQgK (%build) ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` used modified 5.8.1 version ``` * **Operating System**: ``` [root@sbc-stage-a0 SPECS]# cat /etc/os-release NAME="Fedora Linux" VERSION="40 (Container Image)" ID=fedora VERSION_ID=40 VERSION_CODENAME="" PLATFORM_ID="platform:f40" PRETTY_NAME="Fedora Linux 40 (Container Image)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:40" DEFAULT_HOSTNAME="fedora" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=40 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=40 SUPPORT_END=2025-05-13 VARIANT="Container Image" VARIANT_ID=container ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3855 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3855(a)github.com>

2 3

[kamailio/kamailio] extented haproxy protocol support (PR #3731)
by sergey-safarov 12 Jul '24

12 Jul '24

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [ ] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #3667 #### Description Allow creating Record-Route and Via header using destination address and port in the haproxy protocol header. PR created behalf @ivanuschak You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3731 -- Commit Summary -- * core: extented haproxy protocol parser * rr: extented haproxy protocol suppport * path: extented haproxy protocol suppport * websocket: extented haproxy protocol suppport * siptrace: extented haproxy protocol suppport -- File Changes -- M src/core/forward.h (4) M src/core/msg_translator.c (137) M src/core/parser/msg_parser.h (1) M src/core/receive.c (6) M src/core/receive.h (3) M src/core/tcp_conn.h (1) M src/core/tcp_main.c (22) M src/core/tcp_read.c (20) M src/modules/path/path.c (2) M src/modules/rr/loose.c (4) M src/modules/rr/record.c (6) M src/modules/siptrace/siptrace.c (89) M src/modules/websocket/ws_frame.c (9) M src/modules/websocket/ws_handshake.c (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3731.patch https://github.com/kamailio/kamailio/pull/3731.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3731 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3731(a)github.com>

6 22

[kamailio/kamailio] WIP pkg: RPM packaging add kamailio-tls_wolfssl subpackage (PR #3592)
by space88man 09 Jul '24

09 Jul '24

#### Pre-Submission Checklist    - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [X] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description Not for merging yet. Package tls_wolfssl as an alternative to OpenSSL 3.x. Depends on PR https://github.com/kamailio/kamailio/pull/3590 You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3592 -- Commit Summary -- * pkg: RPM packaging add kamailio-tls_wolfssl subpackage -- File Changes -- M pkg/kamailio/obs/kamailio.spec (18) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3592.patch https://github.com/kamailio/kamailio/pull/3592.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3592 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3592(a)github.com>

5 27

[kamailio/kamailio] performance regression related to new TCP connection tracking feature with a high number of connections (Issue #3759)
by Henning Westerholt 05 Jul '24

05 Jul '24

### Description On systems with a high number of TCP sessions there can be a significant performance regression observed, probably related to the newly added TCP connection tracking feature. ### Troubleshooting #### Reproduction No special configuration is necessary, just install the latest 5.7.x release, e.g. 5.7.3 on a production system with a lot of clients connected over TCP or TLS. You need to have a large number of clients connected to be able to observe the regression. For a high number of connections (e.g. more then 20.000 up to 30.000 connections) the Kamailio servers uses about 30% to 50% more CPU as with the old version. #### Debugging Data Two graphs were attached to this issue. The first shows the CPU load before (less load) and after the upgrade (increased load). The second is a flamegraph that shows that over 80% of the CPU time is spent in the newly added function tcp_connection_limit_srcip(). <img width="372" alt="cpu-load-before-after" src="https://github.com/kamailio/kamailio/assets/6481937/ec92c41b-25e2-4847-a4bc…"> ![flamegraph](https://github.com/kamailio/kamailio/assets/6481937/5c2e3982-2d5b-4acd-a774-bad8fa64bd0a) Most of the CPU time is spend in the TCP main process, as expected. #### Log Messages No special log messages could be observed. #### SIP Traffic ### Possible Solutions The TCP limit feature should probably be optimized to not cause such a large performance regression. It should be also possible to deactivate it completly and therefore getting a comparable performance as before the feature addition. ### Additional Information Kamailio 5.7.3 and probably also git master version. * **Operating System**: Debian 11, Debian 12 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3759 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3759(a)github.com>

2 6

[kamailio/kamailio] tcpops module event_route[tcp:closed] route block $conid is null (Issue #3767)
by liangbaolin 05 Jul '24

05 Jul '24

### Description During the process of using version 5.7.4 of Kamailio, I found that the $conid cannot be correctly obtained in the TCP: closed routing block of the TCP module event_route. I am certain that it is normal in version 5.4.8. ### Troubleshooting ``` pv [pv_core.c:2725]: pv_get_tcpconn_id() ``` #### Reproduction The test scenario initiated a register registration process for me, and after completing the disconnection of the TCP connection, triggered this event. #### Log Messages  ``` 2024-02-26T01:35:55.902002512Z 52(98) DEBUG: <core> [core/receive.c:635]: receive_msg(): cleaning up 2024-02-26T01:35:55.902034482Z 52(98) DEBUG: <core> [core/tcp_read.c:280]: tcp_read_data(): EOF on connection 0x7f99a1546a80 (state: 0, flags: c018) - FD 24, bytes 0, rd-flags 10000 ([12.0.1.6]:15821 -> [12.0.1.6]:5060)52(98) DEBUG: <core> [core/tcp_read.c:343]: tcp_read(): read 0 bytes: 2024-02-26T01:35:55.902051542Z 2024-02-26T01:35:55.902058282Z 52(98) DEBUG: <core> [core/tcp_read.c:1532]: tcp_read_req(): read= 0 bytes, parsed=0, state=0, error=1 2024-02-26T01:35:55.902063282Z 52(98) DEBUG: <core> [core/tcp_read.c:1534]: tcp_read_req(): last char=0x00, parsed msg= 2024-02-26T01:35:55.902069402Z 2024-02-26T01:35:55.902074032Z 52(98) DEBUG: <core> [core/tcp_read.c:1544]: tcp_read_req(): EOF 2024-02-26T01:35:55.902101372Z 52(98) DEBUG: <core> [core/io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0x559e8a029740, 24, -1, 0x10) fd_no=2 called 2024-02-26T01:35:55.902153162Z 52(98) DEBUG: <core> [core/tcp_read.c:1927]: handle_io(): removing from list 0x7f99a1546a80 id 2 fd 24, state 2, flags c018, main fd 134, refcnt 2 ([12.0.1.6]:15821 -> [12.0.1.6]:5060) 2024-02-26T01:35:55.902168112Z 52(98) DEBUG: <core> [core/tcp_read.c:1702]: release_tcpconn(): releasing con 0x7f99a1546a80, state -1, fd=24, id=2 ([12.0.1.6]:15821 -> [12.0.1.6]:5060) 2024-02-26T01:35:55.902173372Z 52(98) DEBUG: <core> [core/tcp_read.c:1705]: release_tcpconn(): extra_data (nil) 2024-02-26T01:35:55.902208402Z 83(129) DEBUG: <core> [core/tcp_main.c:3747]: handle_tcp_child(): reader response= 7f99a1546a80, -1 from 1 2024-02-26T01:35:55.902224742Z 83(129) DEBUG: <core> [core/tcp_main.c:3904]: handle_tcp_child(): case CONN_EOF tcp_emit_closed_event before 5 2024-02-26T01:35:55.902229802Z 83(129) DEBUG: <core> [core/tcp_main.c:3671]: tcp_emit_closed_event(): TCP closed event creation triggered (reason: 0) 2024-02-26T01:35:55.902318572Z 83(129) DEBUG: tcpops [tcpops.c:311]: tcpops_handle_tcp_closed(): received TCP closed event 2024-02-26T01:35:55.902331352Z 83(129) DEBUG: tcpops [tcpops.c:261]: tcpops_tcp_closed_run_route(): event reason id: 0 rt: 1 2024-02-26T01:35:55.902335132Z 83(129) ERROR: tcpops [tcpops.c:278]: tcpops_tcp_closed_run_route(): run_top_route() before tev->id: 2 2024-02-26T01:35:55.902480972Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 2 port 0 2024-02-26T01:35:55.902493872Z 83(129) DEBUG: pv [pv_core.c:2725]: pv_get_tcpconn_id(): no conid 2024-02-26T01:35:55.902498762Z 83(129) DEBUG: pv [pv_core.c:2726]: pv_get_tcpconn_id(): msg->rcv.proto_reserved1: 2 2024-02-26T01:35:55.902503592Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 2 port 0 2024-02-26T01:35:55.902508262Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 111 2024-02-26T01:35:55.902513422Z 83(129) ERROR: <script>: tcp connection closed conid: (<null>), tcp(conid): <null>, Ri: 12.0.1.185, Rp: 5060 , si: 12.0.1.6 , sp: 15821 2024-02-26T01:35:55.902607692Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 2 port 0 2024-02-26T01:35:55.902625622Z 83(129) DEBUG: pv [pv_core.c:2725]: pv_get_tcpconn_id(): no conid 2024-02-26T01:35:55.902630672Z 83(129) DEBUG: pv [pv_core.c:2726]: pv_get_tcpconn_id(): msg->rcv.proto_reserved1: 2 2024-02-26T01:35:55.902635822Z 83(129) ERROR: tcpops [tcpops.c:280]: tcpops_tcp_closed_run_route(): run_top_route() after tev->id: 2 2024-02-26T01:35:58.777642759Z 41(87) DEBUG: ims_dialog [dlg_handlers.c:2026]: print_all_dlgs(): ********************41(87) DEBUG: ims_dialog [dlg_handlers.c:2027]: print_all_dlgs(): printing 65536 dialogs ``` #### SIP Traffic  ``` my test script block event_route[tcp:closed] { xlog("L_ERR", "$proto connection closed conid: ($conid), tcp(conid): $tcp(conid), Ri: $Ri, Rp: $Rp , si: $si , sp: $sp\n"); } file: src/modules/pv/pv_core.c int pv_get_tcpconn_id(struct sip_msg *msg, pv_param_t *param, pv_value_t *res) { ... if((con = tcpconn_get(msg->rcv.proto_reserved1, 0, 0, 0, 0)) == NULL) // return false { LM_DBG("no conid\n"); //additional custom log LM_DBG("msg->rcv.proto_reserved1: %d\n",msg->rcv.proto_reserved1); return pv_get_null(msg, param, res); } .... } file: src/core/tcp_main.c struct tcp_connection *tcpconn_lookup(int id, struct ip_addr *ip, int port, union sockaddr_union *local_addr, int try_local_port, ticks_t timeout) { ... if(unlikely(c == NULL)) { c = _tcpconn_find(id, ip, port, &local_ip, local_port); // retrun c == null } ... } struct tcp_connection *_tcpconn_find( int id, struct ip_addr *ip, int port, struct ip_addr *l_ip, int l_port) { ... if(likely(id)) { hash = tcp_id_hash(id); for(c = tcpconn_id_hash[hash]; c; c = c->id_next) { //tcpconn_id_hash find c is null #ifdef EXTRA_DEBUG LM_DBG("c=%p, c->id=%d, port=%d\n", c, c->id, c->rcv.src_port); print_ip("ip=", &c->rcv.src_ip, "\n"); #endif .... } inline static int tcpconn_try_unhash(struct tcp_connection *tcpconn) { ... _tcpconn_detach(tcpconn); //executed ... lock_release(&tcpconn->write_lock); ... } static inline void _tcpconn_detach(struct tcp_connection *c) { ... tcpconn_listrm(tcpconn_id_hash[c->id_hash], c, id_next, id_prev); //remove c ... } ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.4 (x86_64/linux) 9920d9-dirty flags: , EXTRA_DEBUGUSE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 9920d9 -dirty compiled on 09:59:52 Feb 26 2024 with gcc 7.5.0 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3767 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3767(a)github.com>

5 8

[kamailio/kamailio] secsipid method to only validate signature without checking the rest of the header (Issue #3784)
by Ben Kaufman 05 Jul '24

05 Jul '24

### Description Currently secsipid has a method to sign arbitrary (json) data (`secsipid_sign`), however it has no converse method to check the signature. Currently, an attempt to check a `div` signature for example will yield a `-303` error (`SIPHdrInfo`). Rather than trying to have full parsing for every possible type of Identity header (which are likely to increase in variety), it would be good to simply check "is this signature valid by trusted key", possibly validating the `iat` timestamp as well, but without any other opinions on the header values. ### Expected behavior A feature to check only the signature of an identity header. #### Actual observed behavior Currently the `secsipid_check_` family of functions fails for non- `shaken` passport types. #### Debugging Data The following DIV identity header was generated by secsipid's `secsipid_sign()` function, so it should be possible to reverse this to validate the signature: ``` Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9kLm10c2VjLm1lL2QzYTkvQmZUeGJVTlozS1FMLnBlbSJ9.eyJkZXN0Ijp7InRuIjpbIjE2MTI1NTU0MzIxIl19LCJpYXQiOiIxNzEwMTY5MzQ1Iiwib3JpZyI6eyJ0biI6IjE1NTU3MzU5MzA5In0sImRpdiI6eyJ0biI6IjE5NTI1NTU5ODc2In19.-0QF6-u6zgAQNoAhdiETuhAu7FuRDzxmFch_cTdhcbeWvUZ60NQXxdPM-JucpOtFaEdn9wnFreAZ_6vZoc_Phg;info=<https://d.mtsec.me/d3a9/BfTxbUNZ3KQL.pem>;alg=ES256;ppt=div ``` ### Possible Solutions Because it's fairly straight forward to investigate the JWT, it's not necessary to try to account for every possible passport type, etc. The act of validating the signature is the complicated part, so a function that does only that would be convenient. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ``` * **Operating System**: Currently alpine linux 3.19 in a docker container, but it should be pretty reproducible everywhere. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3784 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3784(a)github.com>

3 12

[kamailio/kamailio] Kamailio core dum v5.6 (Issue #3859)
by itpanda2024 04 Jul '24

04 Jul '24

we use Kamailio v5.6 and run cncxx module but when run cncxx function , it restart kamailio service and infor core dump -Log ; ay 28 10:08:30 KAM02 kamailio[45289]: 35(45289) ERROR: {1 83879051 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: check : 2 35(45289) INFO: {1 83879051 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: CDR Recording May 28 10:08:30 KAM02 kamailio[45289]: 35(45289) INFO: {1 83879051 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: check source and dest : 0 va 0 May 28 10:08:30 KAM02 kamailio[45289]: 35(45289) INFO: {1 83879051 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: thông tin nmp : May 28 10:08:30 KAM02 kamailio[45289]: 35(45289) INFO: {1 83879051 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: vao 20 May 28 10:08:30 KAM02 kamailio[45289]: 35(45289) INFO: {1 83879051 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: vao 3 May 28 10:08:30 KAM02 kamailio[45289]: 35(45289) ERROR: {1 83879051 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: huong goi t1 giong t2 \n35(45289) ERROR: {1 83879051 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: cap nhạt update fail route May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: check : 1 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: telco id 1: 1 \n 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: payment_method: 1 May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: IP telco 1: 1 May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: credit_money : 10.000000 May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: customer_id : htc May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: start_cost : 0.000 May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: cps : 0 May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: initial_p : 0 May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: final_p : 0 May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) INFO: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} app_perl [kamailioxs.xs:489]: XS_Kamailio_log(): >>> input: 10.000000, 0, <= May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) INFO: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} app_perl [kamailioxs.xs:489]: XS_Kamailio_log(): >>> return -1 May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: check credit : -1 May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: check cuoc realtime May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: IP telco 2: 1 May 28 10:08:30 KAM02 kamailio[45257]: 3(45257) ERROR: {1 83965494 INVITE 592b5ff7-9742-123d-7eb8-00505697ee23} <script>: cap nhạt update fail route May 28 10:08:35 KAM02 kamailio[45262]: 8(45262) ERROR: {1 83965494 ACK 592b5ff7-9742-123d-7eb8-00505697ee23} uac [replace.c:660]: restore_uri(): new URI [] shorter than old URI [sip:0868233455@125.212.210.235:65000] May 28 10:08:36 KAM02 kernel: traps: kamailio[45361] trap divide error ip:7f0ebbc39ec7 sp:7fffe1365020 error:0 in cnxcc.so[7f0ebbc39000+3c000] May 28 10:08:36 KAM02 systemd[1]: Started Process Core Dump (PID 46616/UID 0). May 28 10:08:37 KAM02 systemd-coredump[46617]: Process 45361 (kamailio) of user 982 dumped core.#012#012Stack trace of thread 45361:#012#0 0x00007f0ebbc39ec7 check_calls_by_money (cnxcc.so + 0x3ec7)#012#1 0x00000000006c5f2a fork_basic_timer (kamailio + 0x2c5f2a)#012#2 0x00007f0ebbc41a2c __child_init (cnxcc.so + 0xba2c)#012#3 0x0000000000636f94 init_mod_child (kamailio + 0x236f94)#012#4 0x0000000000636bde init_mod_child (kamailio + 0x236bde)#012#5 0x000000000063778f init_child (kamailio + 0x23778f)#012#6 0x000000000042f78d main_loop (kamailio + 0x2f78d)#012#7 0x000000000043995c main (kamailio + 0x3995c)#012#8 0x00007f0ec2629590 __libc_start_call_main (libc.so.6 + 0x29590)#012#9 0x00007f0ec2629640 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x29640)#012#10 0x000000000041dc35 _start (kamailio + 0x1dc35)#012ELF object binary architecture: AMD x86-64 May 28 10:08:37 KAM02 systemd[1]: systemd-coredump(a)4-46616-0.service: Deactivated successfully. May 28 10:08:37 KAM02 kamailio[45363]: 109(45363) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 115 May 28 10:08:37 KAM02 kamailio[45254]: 0(45254) ALERT: <core> [main.c:783]: handle_sigs(): child process 45361 exited by a signal 8 May 28 10:08:37 KAM02 kamailio[45254]: 0(45254) ALERT: <core> [main.c:787]: handle_sigs(): core was generated May 28 10:08:37 KAM02 kamailio[45254]: 0(45254) INFO: <core> [main.c:810]: handle_sigs(): terminating due to SIGCHLD May 28 10:08:37 KAM02 kamailio[45256]: 2(45256) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45259]: 5(45259) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45359]: 105(45359) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45260]: 6(45260) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45262]: 8(45262) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45264]: 10(45264) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45267]: 13(45267) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45357]: 103(45357) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45271]: 17(45271) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45273]: 19(45273) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45265]: 11(45265) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45263]: 9(45263) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45276]: 22(45276) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45353]: 99(45353) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45278]: 24(45278) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45281]: 27(45281) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45283]: 29(45283) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45269]: 15(45269) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45268]: 14(45268) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45362]: 108(45362) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45285]: 31(45285) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45288]: 34(45288) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45274]: 20(45274) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45272]: 18(45272) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45280]: 26(45280) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45275]: 21(45275) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45286]: 32(45286) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45352]: 98(45352) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45290]: 36(45290) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45294]: 40(45294) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45277]: 23(45277) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45296]: 42(45296) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45279]: 25(45279) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45299]: 45(45299) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45304]: 50(45304) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45257]: 3(45257) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45306]: 52(45306) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45282]: 28(45282) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45308]: 54(45308) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45300]: 46(45300) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45284]: 30(45284) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45302]: 48(45302) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45255]: 1(45255) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45287]: 33(45287) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45310]: 56(45310) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45315]: 61(45315) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45295]: 41(45295) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45258]: 4(45258) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45297]: 43(45297) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45301]: 47(45301) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45312]: 58(45312) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45314]: 60(45314) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45292]: 38(45292) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45303]: 49(45303) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45317]: 63(45317) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45305]: 51(45305) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45261]: 7(45261) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45360]: 106(45360) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45319]: 65(45319) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45321]: 67(45321) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45307]: 53(45307) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45323]: 69(45323) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45309]: 55(45309) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45289]: 35(45289) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45311]: 57(45311) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45348]: 94(45348) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45340]: 86(45340) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45313]: 59(45313) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45291]: 37(45291) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45316]: 62(45316) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45318]: 64(45318) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45293]: 39(45293) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45324]: 70(45324) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45270]: 16(45270) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45320]: 66(45320) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45266]: 12(45266) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45332]: 78(45332) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45326]: 72(45326) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45322]: 68(45322) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45356]: 102(45356) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45328]: 74(45328) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45330]: 76(45330) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45325]: 71(45325) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45327]: 73(45327) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45334]: 80(45334) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45329]: 75(45329) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45331]: 77(45331) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45336]: 82(45336) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45333]: 79(45333) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45335]: 81(45335) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45338]: 84(45338) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45342]: 88(45342) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45344]: 90(45344) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45346]: 92(45346) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45354]: 100(45354) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45339]: 85(45339) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45337]: 83(45337) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45351]: 97(45351) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45349]: 95(45349) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45341]: 87(45341) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45355]: 101(45355) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45343]: 89(45343) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45358]: 104(45358) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45350]: 96(45350) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45345]: 91(45345) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45347]: 93(45347) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45298]: 44(45298) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45363]: 109(45363) INFO: <core> [main.c:866]: sig_usr(): signal 15 received May 28 10:08:37 KAM02 kamailio[45254]: 0(45254) INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized May 28 10:08:37 KAM02 systemd[1]: kamailio.service: Main process exited, code=exited, status=1/FAILURE May 28 10:08:37 KAM02 systemd[1]: kamailio.service: Failed with result 'exit-code'. May 28 10:08:37 KAM02 systemd[1]: kamailio.service: Consumed 1.023s CPU time. May 28 10:08:37 KAM02 systemd[1]: kamailio.service: Scheduled restart job, restart counter is at 2. May 28 10:08:37 KAM02 systemd[1]: Stopped kamailio - the Open Source SIP Server. May 28 10:08:37 KAM02 systemd[1]: kamailio.service: Consumed 1.023s CPU time. May 28 10:08:37 KAM02 systemd[1]: Started kamailio - the Open Source SIP Server. May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: rtimer [rtimer_mod.c:299]: stm_t_param(): created rtimer name=cdr interval=300 mode=1 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: <core> [core/tcp_main.c:5105]: init_tcp(): using epoll_lt as the io watch method (auto detected) May 28 10:08:37 KAM02 kamailio[46624]: Listening on May 28 10:08:37 KAM02 kamailio[46624]: udp: 125.212.210.235:65000 May 28 10:08:37 KAM02 kamailio[46624]: udp: 172.16.172.245:65000 May 28 10:08:37 KAM02 kamailio[46624]: udp: 172.16.172.246:65000 May 28 10:08:37 KAM02 kamailio[46624]: Aliases: May 28 10:08:37 KAM02 kamailio[46624]: udp: KAM02:65000 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: http_client [http_client.c:316]: mod_init(): HTTP proxy port set to 0. Disabling HTTP proxy May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: regex [regex_mod.c:375]: load_pcres(): num groups = 4 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: regex [regex_mod.c:377]: load_pcres(): <group[0]>((^09[03]\d{7}$#015)|(^089\d{7}$#015)|(^07\d{8}$#015))</group[0]> (size = 45) May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: regex [regex_mod.c:377]: load_pcres(): <group[1]>((^09[6-8]\d{7}$#015)|(^086\d{7}$#015)|(^03\d{8}$#015))</group[1]> (size = 46) May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: regex [regex_mod.c:377]: load_pcres(): <group[2]>((^09[14]\d{7}$#015)|(^08[1-58]\d{7}$#015))</group[2]> (size = 37) May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: regex [regex_mod.c:377]: load_pcres(): <group[3]>((^02[48]\d{8}$#015)|(^842[48]\d{8}$))</group[3]> (size = 35) May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) WARNING: outbound [outbound_mod.c:117]: mod_init(): "stun" module is not loaded. STUN is required to use outbound with UDP. May 28 10:08:37 KAM02 kamailio[46624]: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version. May 28 10:08:37 KAM02 kamailio[46624]: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version. May 28 10:08:37 KAM02 kamailio[46624]: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version. May 28 10:08:37 KAM02 kamailio[46624]: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version. May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: pike [pike.c:93]: pike_init(): PIKE - initializing May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: pike [ip_tree.c:79]: init_lock_set(): probing 256 set size May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: app_perl [app_perl_mod.c:210]: parser_init(): setting lib path: '/usr/local/lib64/kamailio/perl/' May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: app_perl [app_perl_mod.c:242]: parser_init(): successfully loaded perl file "/usr/local/etc/plugin/realtime-payment/scripts/aaa-script.pl" May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: app_perl [app_perl_mod.c:345]: mod_init(): perl interpreter has been initialized (1716865717.772062 => 1716865717.813451) May 28 10:08:37 KAM02 kamailio[46624]: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version. May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: dispatcher [dispatch.c:407]: pack_dest(): uri without sip scheme - fixing it: 125.212.210.236:65000 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: dispatcher [dispatch.c:407]: pack_dest(): uri without sip scheme - fixing it: 125.212.210.237:65000 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: dispatcher [dispatch.c:407]: pack_dest(): uri without sip scheme - fixing it: 125.212.210.238:65000 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: dispatcher [dispatch.c:407]: pack_dest(): uri without sip scheme - fixing it: 172.16.172.244:65000 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: dispatcher [dispatch.c:407]: pack_dest(): uri without sip scheme - fixing it: 172.16.172.243:65000 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: dispatcher [dispatch.c:407]: pack_dest(): uri without sip scheme - fixing it: 172.16.172.242:65000 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: dispatcher [dispatch.c:407]: pack_dest(): uri without sip scheme - fixing it: 101.99.1.36:5060 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: cnxcc [cnxcc_mod.c:246]: __mod_init(): Loading cnxcc module May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: drouting [drouting.c:279]: dr_init(): DRouting - initializing May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: <core> [main.c:3150]: main(): processes (at least): 110 - shm size: 67108864 - pkg size: 8388608 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) WARNING: tm [tm.c:527]: fixup_routes(): t_on_failure("OUT_FAILURE"): empty/non existing route May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) WARNING: tm [tm.c:527]: fixup_routes(): t_on_failure("OUT_FAILURE"): empty/non existing route May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) WARNING: tm [tm.c:527]: fixup_routes(): t_on_failure("MS_IN_FAILURE"): empty/non existing route May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) WARNING: tm [tm.c:527]: fixup_routes(): t_on_failure("MS_IN_FAILURE"): empty/non existing route May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) WARNING: tm [tm.c:527]: fixup_routes(): t_on_failure("MS_IN_FAILURE"): empty/non existing route May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) WARNING: tm [tm.c:527]: fixup_routes(): t_on_failure("MS_OUT_FAILURE"): empty/non existing route May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 8 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 8 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 9 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 9 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 10 May 28 10:08:37 KAM02 kamailio[46624]: 0(46624) INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 10 May 28 10:08:37 KAM02 kamailio[46625]: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a f -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3859 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3859(a)github.com>

3 15

[kamailio/kamailio] Kamailio became unresponsive during runtime (#2380)
by ObakeFilter 27 Jun '24

27 Jun '24

### Description Hi, I ran into an issue where the Kamailio service seemingly froze (didn't crash, but failed to receive and deliver calls) while running, I went through the logs a little bit, and saw the same log pattern (pasted below) recouring every few months or so, on an older installation (5.2.0). Usually, it ended up automatically restarting the service. But not this time, I had to reload it manually to make the service work again. Is this a known issue? How can I make sure that the service will be able to restart the next time it happens? Edward ### Troubleshooting #### Debugging Data  ``` GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/local/sbin/kamailio...done. warning: exec file is newer than core file. [New LWP 11413] Core was generated by `kamailio'. Program terminated with signal SIGABRT, Aborted. #0 0x00007f4e4a52e428 in ?? () (gdb) Quit (gdb) bt full #0 0x00007f4e4a52e428 in ?? () No symbol table info available. #1 0x00007f4e4a53002a in ?? () No symbol table info available. #2 0x0000000000000020 in ?? () No symbol table info available. #3 0x0000000000000000 in ?? () No symbol table info available. (gdb) info locals No symbol table info available. (gdb) list 1871 & now if we don't need it */ 1872 #ifdef USE_SLOW_TIMER 1873 + 1 /* slow timer process */ 1874 #endif 1875 #ifdef USE_TCP 1876 +((!tcp_disable)?( 1/* tcp main */ + tcp_listeners ):0) 1877 #endif 1878 #ifdef USE_SCTP 1879 +((!sctp_disable)?sctp_listeners:0) 1880 #endif (gdb) ``` #### Log Messages  ``` Jun 28 16:35:22 kamprodegres kamailio: INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Jun 28 16:35:22 kamprodegres kamailio: WARNING: <core> [core/socket_info.c:1394]: fix_hostname(): could not rev. resolve 70.36.25.87 Jun 28 16:35:22 kamprodegres kamailio: WARNING: <core> [core/socket_info.c:1394]: fix_hostname(): could not rev. resolve 70.36.25.87 Jun 28 16:35:22 kamprodegres kamailio: INFO: <core> [core/tcp_main.c:5042]: init_tcp(): using epoll_lt as the io watch method (auto detected) Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: jsonrpcs [jsonrpcs_sock.c:197]: jsonrpc_dgram_mod_init(): the socket /var/run/kamailio/kamailio_rpc.sock already exists, trying to delete it... Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: rr [rr_mod.c:177]: mod_init(): outbound module not available Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [main.c:2779]: main(): processes (at least): 40 - shm size: 67108864 - pkg size: 8388608 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Jun 28 16:35:22 kamprodegres kamailio[8489]: INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Jun 28 16:35:22 kamprodegres kamailio[8518]: INFO: jsonrpcs [jsonrpcs_sock.c:443]: jsonrpc_dgram_process(): a new child 0/8518 Jun 28 16:35:22 kamprodegres kamailio[8519]: INFO: ctl [io_listener.c:214]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) Jun 29 18:13:37 kamprodegres kamailio[8513]: INFO: {1 581461 CANCEL 402954192_49936786(a)67.231.13.146} tm [t_reply.c:478]: _reply_light(): can't generate 487 reply when a final 404 was sent out Jun 29 18:27:00 kamprodegres kamailio[8508]: INFO: {1 211236 CANCEL 405019408_127896329(a)67.231.13.146} tm [t_reply.c:478]: _reply_light(): can't generate 487 reply when a final 404 was sent out Jun 29 18:51:10 kamprodegres /usr/local/sbin/kamailio[2269]: NOTICE: <core> [main.c:725]: handle_sigs(): Thank you for flying kamailio!!! Jun 29 18:51:10 kamprodegres /usr/local/sbin/kamailio[2326]: INFO: <core> [main.c:847]: sig_usr(): signal 15 received ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.3.2 (x86_64/linux) 7ba545 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 7ba545 compiled on 16:37:32 Jun 14 2020 with gcc 5.4.0 ``` * **Operating System**:  ``` Ubuntu 16.04 ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2380

3 10

[kamailio/kamailio] Kamailio 5.6 (and 5.7) core dumps. (Issue #3725)
by Mattis Lind 19 Jun '24

19 Jun '24

### Description We have a quite basic scenario which sends a SIP MESSAGE and then receives SIP MESSAGE back. It also sets up two voice calls using SIP INVITE. It is only this specific scenario that is causing the core dump. Some time the core dump occur just a few seconds after the call/message scenario, but occasionally it takes up to 50 minutes. We have been using the uac module for sending SIP MESSAGE in several other scenarios without experiencing a crash. We always see the same lines in the log just prior to the core dump: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 49 We are using Kamailio 5.6 retrieved from the kamailio repository: http://deb.kamailio.org/kamailio56. We are running Kamailio in a Docker container which runs on "5.10.0-25-cloud-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16) x86_64 GNU/Linux" We have also tried Kamailio 5.7 from the same repo which crashes in exactly the same way. ### Troubleshooting #### Reproduction We have troubles to consistently reproduce it and it only happen from time to time when running a specific scenario sending SIP MESSAGE using the uac module. It does not happen for every call of this call scenario. At one instance Kamailo crashed with just 15 seconds in-between during the call scenario. #### Debugging Data ``` # gdb /usr/sbin/kamailio /core GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/sbin/kamailio... (No debugging symbols found in /usr/sbin/kamailio) warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing [New LWP 4777] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/sbin/kamailio -DD -M 18 -m 192 -A serverId=17173 -A sendTraceLocal="sip:10'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __strlen_evex () at ../sysdeps/x86_64/multiarch/strlen-evex.S:77 77 ../sysdeps/x86_64/multiarch/strlen-evex.S: No such file or directory. (gdb) bt full #0 __strlen_evex () at ../sysdeps/x86_64/multiarch/strlen-evex.S:77 No locals. #1 0x00007f5425e34b78 in __vfprintf_internal (s=s@entry=0x55a06e969a60, format=format@entry=0x55a06e558020 "%s: %.*s%s%s%sBUG: qm: fragm. %p (address %p) beginning overwritten (%lx)! Memory allocator was called from %s:%u. Fragment marked by %s:%lu. Exec from %s:%u.\n", ap=ap@entry=0x7ffd6bebfb50, mode_flags=mode_flags@entry=0) at vfprintf-internal.c:1647 len = <optimized out> step0_jumps = {0, 1717, 1621, 3413, 3317, 3997, 2677, 2837, 3613, 1773, 4309, 4445, 3517, 4437, 4389, 2789, 4197, 3917, 3221, 2997, 1141, 1365, 1997, 1925, 1885, 733, 3709, 533, 533, 4101} space = <optimized out> is_short = <optimized out> use_outdigits = 0 outc = <optimized out> step1_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 1773, 4309, 4445, 3517, 4437, 4389, 2789, 4197, 3917, 3221, 2997, 1141, 1365, 1997, 1925, 1885, 733, 3709, 533, 533, 0} group = 0 prec = -1 step2_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4309, 4445, 3517, 4437, 4389, 2789, 4197, 3917, 3221, 2997, 1141, 1365, 1997, 1925, 1885, 733, 3709, 533, 533, 0} string = 0x756d6f7266222c22 <error: Cannot access memory at address 0x756d6f7266222c22> left = 0 is_long_double = <optimized out> width = 0 signed_number = <optimized out> step3a_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4213, 0, 0, 0, 4389, 2789, 4197, 3917, 3221, 0, 0, 0, 0, 1925, 0, 0, 0, 0, 0, 0} alt = <optimized out> showsign = 0 is_long = 0 is_char = <optimized out> pad = <optimized out> step3b_jumps = {0 <repeats 11 times>, 3517, 0, 0, 4389, 2789, 4197, 3917, 3221, 2997, 1141, 1365, 1997, 1925, 1885, 733, 3709, 0, 0, 0} step4_jumps = {0 <repeats 14 times>, 4389, 2789, 4197, 3917, 3221, 2997, 1141, 1365, 1997, 1925, 1885, 733, 3709, 0, 0, 0} args_value = <optimized out> is_negative = <optimized out> number = {longlong = <optimized out>, word = <optimized out>} base = <optimized out> the_arg = {pa_wchar = 4777 L'\x12a9', pa_int = 4777, pa_long_int = 4777, pa_long_long_int = 4777, pa_u_int = 4777, pa_u_long_int = 4777, pa_u_long_long_int = 4777, pa_double = 2.3601515901836347e-320, pa_long_double = 1.74131181638025811763e-4947, pa_float128 = 3.09319115455554459548860449034534676e-4962, pa_string = 0x12a9 <error: Cannot access memory at address 0x12a9>, pa_wstring = 0x12a9 <error: Cannot access memory at address 0x12a9>, pa_pointer = 0x12a9, pa_user = 0x12a9} spec = 115 's' _buffer = {__routine = 0x4, __arg = 0xd, __canceltype = 1855363680, __prev = 0xe0} _avail = <optimized out> thousands_sep = 0x0 grouping = 0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff> done = 238 f = 0x55a06e5580a7 "s:%lu. Exec from %s:%u.\n" lead_str_end = 0x55a06e558020 "%s: %.*s%s%s%sBUG: qm: fragm. %p (address %p) beginning overwritten (%lx)! Memory allocator was called from %s:%u. Fragment marked by %s:%lu. Exec from %s:%u.\n" end_of_spec = <optimized out> work_buffer = "h\r\000\000\000\000\000\000\000\000\000\000\060\000\000\000\000\000\000\000\375\177\000\000 \372\353k\375\177\000\000\237MSn\n\000\000\000\000\000\000\000\240U", '\000' <repeats 18 times>, "P\225Un\240U\000\000\000\000\000\000[\214A\323\f\000\000\000\000\000\000\000\377\377\377\377\377\377\377\377\206\002", '\000' <repeats 14 times>, "\004\000\000\000\000\000\000\000 \367\353k\375\177\000\000\301\225Un\240U\000\000\323\262\vn\240U\000\000\000\000\000\000\000\000\000\000s\374On\240U\000\000W\225Un\240U\000\000\350>\212\027T\177\000\000 \323\365$T\177\000\000\060\a\354k\375\177\000\00--Type <RET> for more, q to quit, c to continue without paging-- 0\220\371\227n\240U\000\000"... workend = 0x7ffd6bebf9f8 "" ap_save = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7ffd6bebfc30, reg_save_area = 0x7ffd6bebfb70}} nspecs_done = 10 save_errno = 4 readonly_format = 0 do_longlong_number = <optimized out> __result = <optimized out> #2 0x00007f5425ec079f in __vsyslog_internal (pri=<optimized out>, fmt=0x55a06e558020 "%s: %.*s%s%s%sBUG: qm: fragm. %p (address %p) beginning overwritten (%lx)! Memory allocator was called from %s:%u. Fragment marked by %s:%lu. Exec from %s:%u.\n", ap=0x7ffd6bebfb50, mode_flags=0) at ../misc/syslog.c:233 now_tm = {tm_sec = 8, tm_min = 18, tm_hour = 12, tm_mday = 23, tm_mon = 0, tm_year = 124, tm_wday = 2, tm_yday = 22, tm_isdst = 0, tm_gmtoff = 0, tm_zone = 0x55a06e94c5e0 "UTC"} now = 1706012288 fd = <optimized out> f = 0x55a06e969a60 buf = 0x0 bufsize = 0 msgoff = 21 saved_errno = <optimized out> failbuf = "`\232\226n\240U\000\000\000\204\201\247[\214A\323`\374\353k\375\177\000\000\300p\371%T" clarg = {buf = <optimized out>, oldaction = <optimized out>} #3 0x00007f5425ec0c46 in __syslog (pri=<optimized out>, fmt=<optimized out>) at ../misc/syslog.c:117 ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x7ffd6bebfc70, reg_save_area = 0x7ffd6bebfb70}} #4 0x000055a06e3b7839 in ?? () No symbol table info available. #5 0x000055a06e3bc039 in qm_free () No symbol table info available. #6 0x000055a06e3c7c28 in qm_shm_free () No symbol table info available. #7 0x00007f542325fb8e in uac_send_tm_callback () from /usr/lib/x86_64-linux-gnu/kamailio/modules/uac.so No symbol table info available. #8 0x00007f5424a2f002 in run_trans_callbacks_internal () from /usr/lib/x86_64-linux-gnu/kamailio/modules/tm.so No symbol table info available. #9 0x00007f5424a2f179 in run_trans_callbacks () from /usr/lib/x86_64-linux-gnu/kamailio/modules/tm.so No symbol table info available. #10 0x00007f54249d5e8c in free_cell_helper () from /usr/lib/x86_64-linux-gnu/kamailio/modules/tm.so No symbol table info available. #11 0x00007f5424aa8f82 in wait_handler () from /usr/lib/x86_64-linux-gnu/kamailio/modules/tm.so No symbol table info available. #12 0x000055a06e37a263 in ?? () No symbol table info available. #13 0x000055a06e37a79d in ?? () No symbol table info available. #14 0x000055a06e37acc6 in timer_main () No symbol table info available. #15 0x000055a06e0a5f62 in main_loop () No symbol table info available. --Type <RET> for more, q to quit, c to continue without paging-- #16 0x000055a06e0b120c in main () No symbol table info available. (gdb) info locals No locals. (gdb) list 72 in ../sysdeps/x86_64/multiarch/strlen-evex.S ``` #### Log Messages ``` Log file: 2024-01-23T13:18:08.828+01:00 Jan 23 12:18:08 /usr/sbin/kamailio[4789]: INFO: <script>: Incoming SIP TCP request conid 21 call-id un0rihsRLJLvP-grn6LO-A 2024-01-23T13:18:08.835+01:00 Jan 23 12:18:08 /usr/sbin/kamailio[4789]: INFO: <script>: Incoming SIP TCP request conid 21 call-id WQjhldpRJbxjZRYe7fWgbw 2024-01-23T13:18:08.860+01:00 Jan 23 12:18:08 /usr/sbin/kamailio[4795]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 49 2024-01-23T13:18:09.486+01:00 Jan 23 12:18:09 /usr/sbin/kamailio[4751]: ALERT: <core> [main.c:783]: handle_sigs(): child process 4777 exited by a signal 11 2024-01-23T13:18:09.486+01:00 Jan 23 12:18:09 /usr/sbin/kamailio[4751]: ALERT: <core> [main.c:787]: handle_sigs(): core was generated 2024-01-23T13:18:09.516+01:00 Jan 23 12:18:09 /usr/sbin/kamailio[4751]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized 2024-01-23T13:18:09.570+01:00 Started /root/sipconfig/startkamailio.sh 2024-01-23T13:18:09.570+01:00 info: :-) Starting Kamailio ``` #### SIP Traffic ### Possible Solutions ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` # /usr/sbin/kamailio -v version: kamailio 5.6.5 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 10.2.1 ``` * **Operating System**: ``` # lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye Linux ip-nn-nn-nn-nn 5.10.0-25-cloud-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3725 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3725(a)github.com>

4 8

[kamailio/kamailio] tls: enable statistics (PR #3852)
by Cedric Müller 17 Jun '24

17 Jun '24

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  This enables tls module statistics. This is needed for the xhttp_prom module to export tls module statistics. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3852 -- Commit Summary -- * tls: enable statistics * tls: code formatting -- File Changes -- M src/modules/tls/tls_mod.c (43) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3852.patch https://github.com/kamailio/kamailio/pull/3852.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3852 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3852(a)github.com>

4 7

[kamailio/kamailio] Kamailio ims_charging module Ro Interface User-Equipment-Info-Type AVP (Issue #3807)
by svinson1121 17 Jun '24

17 Jun '24

The Kamailio ims_charging module Ro interface is sending: AVP: User-Equipment-Info(458) -> AVP: User-Equipment-Info-Type(459) l=12 f=-M- val=MAC (1) see attached Ro.pcapng packet #7. but (unless I'm not understanding correctly) according to TS 132 299 this AVP should be of type IMEISV and not MAC for the Ro charging interface. also, the MAC is not encoded correctly. again, see the attached pcap at packet #7 from TS 132 299: "User-Equipment-Info-Type This field determines the type of the identifier. The used value is 0 for the international mobile equipment identifier and software version according to TS 23.003[224]. User-Equipment-Info-Value This field contains the user IMEI." "For PS charging, when the User-Equipment-Info-Type AVP (AVP code 459) is set to IMEISV (0), the value within the User-Equipment-Info-Value AVP (AVP code 460) is of type OctetString and shall be a UTF-8 encoded hexadecimal. The composition of the IMEISV follows the definition in TS 23.003 [224] . If only IMEI is received a filler ‘F’ is used to make it 16 digits." "For IMS charging, when the User-Equipment-Info-Type AVP (AVP code 459) is set to IMEISV (0), the value within the User-Equipment-Info-Value AVP (AVP code 460) is of type OctetString and shall be a UTF-8 encoded decimal. The composition of the IMEISV follows the definition in TS 23.003 [224]. If only IMEI is received the number of digits are truncated to 15." I have tested and found this in the following versions: version: kamailio 5.9.0-dev0 (x86_64/linux) 4fb8ac version: kamailio 5.3.2 (x86_64/linux) 87e8a1 Thank you so much for your help with this issue, [Ro.zip](https://github.com/kamailio/kamailio/files/14924042/Ro.zip) -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3807 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3807(a)github.com>

4 5

[kamailio/kamailio] 200OK (for deregistration: REGISTER with Expire:0) is not reaching to UE (Issue #3866)
by deepak-git-account 14 Jun '24

14 Jun '24

### Description During de-registration, Kamailio receives REGISTER (with expire 0), and then send Session Termination request, and only after getting Session Termination Answer, Kamailo sends 200OK. This is not sent till UE. The reason is after receiving Session Termination Request, the PCRF sends ReAuthRequest towards PCEF and it followed delete bearer procedure in IMS-PGW and bearer is getting deleted :(.  In the kamailio script, pcscf_save() is used after receiving 200OK from SCSCF. And within this function, STR is sent and STA received. ### Troubleshooting #### Reproduction  RX_SUPPORT flag shall be defined and it can be observed in De-registration procedure. #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` kamailio --version version: kamailio 5.7.5 (x86_64/linux) 58499a-dirty flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 58499a -dirty compiled on 11:23:55 May 8 2024 with gcc 9.4.0 ``` * **Operating System**:  ``` uname -a Linux openims-tvmcfg-node-focal 5.4.0-181-generic #201-Ubuntu SMP Thu Mar 28 15:39:01 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3866 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3866(a)github.com>

1 1

[kamailio/kamailio] Siptrace: setting send_sock_name/send_sock_address is ineffective for tcp based transports (PR #3837)
by Dennis 14 Jun '24

14 Jun '24

For tcp based transports it is need to set SND_F_FORCE_SOCKET flag before msg_send_buffer call, or duplicate will send from wrong addr/port.   #### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3837 -- Commit Summary -- * siptrace: add SND_F_FORCE_SOCKET flag if send_sock_name/send_sock_address config parameters are used -- File Changes -- M src/modules/siptrace/siptrace_send.c (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3837.patch https://github.com/kamailio/kamailio/pull/3837.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3837 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3837(a)github.com>

3 3

[kamailio/kamailio] pike: fix documentation for reqs_density_per_unit (PR #3806)
by tsearle 11 Jun '24

11 Jun '24

#### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3806 -- Commit Summary -- * pike: fix documentation for reqs_density_per_unit -- File Changes -- M src/modules/pike/doc/pike_admin.xml (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3806.patch https://github.com/kamailio/kamailio/pull/3806.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3806 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3806(a)github.com>

5 7

[kamailio/kamailio] pua_dialoginfo fails to publish the caller when not using avps (Issue #3838)
by michelpelletier07 08 Jun '24

08 Jun '24

### Description What I did: I enabled the pua_dialoginfo module to publish changes for both the caller and the callee. What I expected: PUBLISH to be generated for the caller and the callee What actually happened: PUBLISH is only generated for the callee. ### Troubleshooting I troubleshooted the issue by adding LM_ERR messages at various point in the pua_dialoginfo.c #### Reproduction Add a db-url as modparam to pua Do not add any modparam to pua_dialoginfo. Then make a phone call while making sure dialog.dlg_manage() is called to track the call. #### Debugging Data Not applicable #### Log Messages pua_dialoginfo [dialog_publish.c:303]: dialog_publish(): failed to parse the PUBLISH R-URI ### Possible Solutions I tracked the issue to line 840 of pua_dialoginfo.c (see enclosed patch file), where dlginfo->pubruris_caller->s.s is set to the value of dlginfo->from_uri but dlginfo->pubruris_caller->s.len is not set to anything (left at zero). So I added a line to set the len value to the len value of dlginfo->from_uri.len See patch below: ``` diff -ru a/src/modules/pua_dialoginfo/pua_dialoginfo.c b/src/modules/pua_dialoginfo/pua_dialoginfo.c --- a/src/modules/pua_dialoginfo/pua_dialoginfo.c 2024-05-02 11:14:34.150097771 -0600 +++ b/src/modules/pua_dialoginfo/pua_dialoginfo.c 2024-05-02 11:09:30.855960974 -0600 @@ -838,6 +838,8 @@ } memset(dlginfo->pubruris_caller, 0, sizeof(struct str_list)); dlginfo->pubruris_caller->s.s = shm_str2char_dup(&dlginfo->from_uri); + dlginfo->pubruris_caller->s.len = dlginfo->from_uri.len; + if(!dlginfo->pubruris_caller->s.s) { free_dlginfo_cell(dlginfo); return NULL; ``` ### Additional Information version: kamailio 5.8.1 (x86_64/linux) 384843 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 384843 compiled on 13:45:08 May 2 2024 with gcc 10.2.1 * **Operating System**: Linux yto11-stg-smf-vtr1.vcn.ms 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3838 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3838(a)github.com>

3 4

[kamailio/kamailio] Less predictive algorithm for carrierroute hashing (Issue #3786)
by Ben Kaufman 08 Jun '24

08 Jun '24

### Description Carrierroute's CRC32 algorithm over call_id tends to produce poor call distribution under real world examples. Having 4 records for a given carrier/domain combo (assuming no flags, mask, or scan_prefix) and a probability of `0.25` using a hash source of `call_id` I observed over 800 hundred consecutive calls from a carrier (bandwidth.com) where `CRC32(call_id) % 1000` was less than 250. To be fair, the module does what it says - it uses a CRC32 hash over the call id, however the data from the UA generating the call is yielding poor results. Would it be possible to change to an alternate hashing mechanism (or add another hashing mechanism, selectable via `modparam`) such as MD5? ### Expected behavior Even distribution across all hosts provided. #### Actual observed behavior Uneven distribution under real-world conditions. #### Debugging Data I can provide a list of > 800 call-ids observed that all routed to the same endpoint. These are pulled from real world calls, and while there's not much danger in just having call-id's I would still prefer not to post it into github for posterity. #### Log Messages Log messages end up looking similar to this. I validated that the number is the CRC32 hash of the call id, so it's not a bug in the module. ``` proxy-1 | 1(7) DEBUG: carrierroute [cr_func.c:449]: rewrite_on_rule(): searching for matching routing rules 1(7) DEBUG: carrierroute [prime_hash.c:66]: hash_func(): hash: 2417021133 % 1000 = 133 proxy-1 | 1(7) INFO: carrierroute [cr_func.c:689]: ki_cr_do_route_helper(): uri service was rewritten to sip:service@host-d, carrier 1, domain 1 ``` ### Possible Solutions Ability to use MD5, kamailio's core hash function or other such hashing function ### Additional Information Problem validate in 5.7.3, but since it's *correct* by module design, it shouldn't have changed in 5.8 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3786 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3786(a)github.com>

3 4

[kamailio/kamailio] microhttpd cannot be build on CentOS 8 (Issue #3504)
by sergey-safarov 08 Jun '24

08 Jun '24

``` LD (gcc) [M memcached.so] memcached.so CC (gcc) [M microhttpd.so] microhttpd_mod.o microhttpd_mod.c:374:24: error: return type is an incomplete type static enum MHD_Result ksr_microhttpd_request(void *cls, ^~~~~~~~~~~~~~~~~~~~~~ microhttpd_mod.c: In function 'ksr_microhttpd_request': microhttpd_mod.c:390:10: warning: 'return' with a value, in function returning void return MHD_YES; ^~~~~~~ microhttpd_mod.c:374:24: note: declared here static enum MHD_Result ksr_microhttpd_request(void *cls, ^~~~~~~~~~~~~~~~~~~~~~ microhttpd_mod.c:411:10: warning: 'return' with a value, in function returning void return MHD_NO; ^~~~~~ microhttpd_mod.c:374:24: note: declared here static enum MHD_Result ksr_microhttpd_request(void *cls, ^~~~~~~~~~~~~~~~~~~~~~ microhttpd_mod.c:433:10: warning: 'return' with a value, in function returning void return MHD_NO; ^~~~~~ microhttpd_mod.c:374:24: note: declared here static enum MHD_Result ksr_microhttpd_request(void *cls, ^~~~~~~~~~~~~~~~~~~~~~ microhttpd_mod.c:436:9: warning: 'return' with a value, in function returning void return MHD_YES; ^~~~~~~ microhttpd_mod.c:374:24: note: declared here static enum MHD_Result ksr_microhttpd_request(void *cls, ^~~~~~~~~~~~~~~~~~~~~~ microhttpd_mod.c: In function 'microhttpd_server_run': microhttpd_mod.c:462:17: warning: passing argument 5 of 'MHD_start_daemon' from incompatible pointer type [-Wincompatible-p ointer-types] NULL, NULL, &ksr_microhttpd_request, KSR_MICROHTTPD_PAGE, ^~~~~~~~~~~~~~~~~~~~~~~ In file included from microhttpd_mod.c:29: /usr/include/microhttpd.h:2148:1: note: expected 'MHD_AccessHandlerCallback' {aka 'int (*)(void *, struct MHD_Connection *, const char *, const char *, const char *, const char *, long unsigned int *, void **)'} but argument is of type 'void (*)( void *, struct MHD_Connection *, const char *, const char *, const char *, const char *, size_t *, void **)' {aka 'void (*) (void *, struct MHD_Connection *, const char *, const char *, const char *, const char *, long unsigned int *, void **)'} MHD_start_daemon (unsigned int flags, ^~~~~~~~~~~~~~~~ microhttpd_mod.c:467:17: warning: passing argument 5 of 'MHD_start_daemon' from incompatible pointer type [-Wincompatible-p ointer-types] NULL, NULL, &ksr_microhttpd_request, KSR_MICROHTTPD_PAGE, ^~~~~~~~~~~~~~~~~~~~~~~ In file included from microhttpd_mod.c:29: /usr/include/microhttpd.h:2148:1: note: expected 'MHD_AccessHandlerCallback' {aka 'int (*)(void *, struct MHD_Connection *, const char *, const char *, const char *, const char *, long unsigned int *, void **)'} but argument is of type 'void (*)( void *, struct MHD_Connection *, const char *, const char *, const char *, const char *, size_t *, void **)' {aka 'void (*) (void *, struct MHD_Connection *, const char *, const char *, const char *, const char *, long unsigned int *, void **)'} MHD_start_daemon (unsigned int flags, ^~~~~~~~~~~~~~~~ make[2]: *** [../../Makefile.rules:100: microhttpd_mod.o] Error 1 make[1]: Leaving directory '/root/rpmbuild/BUILD/kamailio-5.8.0-dev1/src' make[1]: *** [Makefile:508: modules] Error 1 make: *** [Makefile:34: every-module] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.K7wkd7 (%build) Bad exit status from /var/tmp/rpm-tmp.K7wkd7 (%build) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3504 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3504(a)github.com>

3 3

[kamailio/kamailio] p_usrloc: Add update/delete based on uniq (PR #3865)
by Stefan Mititelu 06 Jun '24

06 Jun '24

#### Pre-Submission Checklist    - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [X] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Add a new update/delete function based on contact's uniq uniq. Some devices may use same uniq for multiple contacts, so I needed to restrain it further based on ruid value. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3865 -- Commit Summary -- * p_usrloc: Add update/delete based on uniq -- File Changes -- M src/modules/p_usrloc/doc/p_usrloc_admin.xml (5) M src/modules/p_usrloc/ucontact.c (307) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3865.patch https://github.com/kamailio/kamailio/pull/3865.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3865 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3865(a)github.com>

2 2

[kamailio/kamailio] pdb: make 'timeout' runtime configurable (PR #3850)
by Stefan Mititelu 05 Jun '24

05 Jun '24

#### Pre-Submission Checklist    - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [X] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Make timeout modparam runtime configurable. Also update timout execeded logs from NOTICE to ERR and add more info to them. Also update utils/pdbt.c query tool to allow 0 carrier id. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3850 -- Commit Summary -- * pdb: make 'timeout' runtime configurable -- File Changes -- A src/modules/pdb/config.c (42) A src/modules/pdb/config.h (37) M src/modules/pdb/pdb.c (40) M utils/pdbt/pdbt.c (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3850.patch https://github.com/kamailio/kamailio/pull/3850.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3850 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3850(a)github.com>

3 5

[kamailio/kamailio] fixed handle_ruri_alias_mode(1) cannot proper handle multi alias (PR #3863)
by Lv Xiaobu 04 Jun '24

04 Jun '24

when receive BYE sip:xxx@xxxx;alias=ip1;alias=ip2 SIP/2.0, handle_ruri_alias_mode(1) doesn't work as documented You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3863 -- Commit Summary -- * fixed handle_ruri_alias_mode(1) cannot proper handle multi alias -- File Changes -- M src/modules/nathelper/nathelper.c (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3863.patch https://github.com/kamailio/kamailio/pull/3863.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3863 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3863(a)github.com>

3 7

[kamailio/kamailio] Crash in dns_cache.c with use_dns_cache=off (Issue #3350)
by Дилян Палаузов 04 Jun '24

04 Jun '24

With Kamailio 5.6.3 I add this code ```diff -- Routing to foreign domains function ksr_route_sipout() + local y = KSR.enum.enum_query() + KSR.err('ENUM RESULT ' .. tostring(y) .. ' :RURI ' .. KSR.kx.get_ruri() .. '\n') if KSR.is_myself_ruri() then return 1; end KSR.hdr.append("P-Hint: outbound\r\n"); ``` and dial +437200101011 . The code above produces the output “ENUM RESULT 1 :RURI sip:enum-test@sip.nemox.net”. I have the DNS-related settings: ``` dns_try_naptr=on use_dns_cache=off dns_cache_init=off ``` Kamailio logs during the dial-in process: ```sip INVITE sip:+437200101011@sip.example.org SIP/2.0 Via: SIP/2.0/UDP 192.168.0.199:40867;rport;branch=z9hG4bKU2Fc14H2NX4Kc Max-Forwards: 70 From: <sip:myself@sip.example.org>;tag=vmjX7H12KrH1B To: <sip:+437200101011@sip.example.org> Call-ID: 8956e785-1905-123c-24bb-e4aaeae9dd8b CSeq: 62865320 INVITE Contact: <sip:myself@sip.example.org> User-Agent: calls sofia-sip/1.13.12 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE Supported: timer, 100rel, replaces, gruu, outbound Content-Type: application/sdp Content-Disposition: session Content-Length: 240 v=0 o=- 9163509233734166984 5909793187606445082 IN IP4 192.168.0.199 s=- c=IN IP4 22.222.222.222 t=0 0 m=audio 43264 RTP/AVP 9 8 0 3 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtcp:33730 6(7) ERROR: <core> [core/kemi.c:96]: sr_kemi_core_err(): ksr_sipdump_event 1--------- sipdump:msg SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 192.168.0.199:40867;rport=40867;branch=z9hG4bKU2Fc14H2NX4Kc;received=22.222.222.222 From: <sip:myself@sip.example.org>;tag=vmjX7H12KrH1B To: <sip:+437200101011@sip.example.org>;tag=44af9dbde0a62ae84f5c1ff272adb901.20dd651d Call-ID: 8956e785-1905-123c-24bb-e4aaeae9dd8b CSeq: 62865320 INVITE Proxy-Authenticate: Digest realm="example.int", nonce="Y9QB/GPUANBJum6LTOLsDnjaSLKc/8o1A1zk1oUtFXzlFe/OfiMEAg==" Content-Length: 0 8(9) ERROR: <core> [core/kemi.c:96]: sr_kemi_core_err(): ksr_sipdump_event 1--------- sipdump:msg ACK sip:+437200101011@sip.example.org SIP/2.0 Via: SIP/2.0/UDP 192.168.0.199:40867;rport;branch=z9hG4bKU2Fc14H2NX4Kc Max-Forwards: 70 From: <sip:myself@sip.example.org>;tag=vmjX7H12KrH1B To: <sip:+437200101011@sip.example.org>;tag=44af9dbde0a62ae84f5c1ff272adb901.20dd651d Call-ID: 8956e785-1905-123c-24bb-e4aaeae9dd8b CSeq: 62865320 ACK Content-Length: 0 5(6) ERROR: <core> [core/kemi.c:96]: sr_kemi_core_err(): ksr_sipdump_event 1--------- sipdump:msg INVITE sip:+437200101011@sip.example.org SIP/2.0 Via: SIP/2.0/UDP 192.168.0.199:40867;rport;branch=z9hG4bKvB942Z25j6t6Q Max-Forwards: 70 From: <sip:myself@sip.example.org>;tag=vmjX7H12KrH1B To: <sip:+437200101011@sip.example.org> Call-ID: 8956e785-1905-123c-24bb-e4aaeae9dd8b CSeq: 62865321 INVITE Contact: <sip:myself@sip.example.org> User-Agent: calls sofia-sip/1.13.12 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE Supported: timer, 100rel, replaces, gruu, outbound Proxy-Authorization: Digest username="myself", realm="example.int", nonce="Y9QB/GPUANBJum6LTOLsDnjaSLKc/8o1A1zk1oUtFXzlFe/OfiMEAg==", algorithm=MD5, uri="sip:+437200101011@sip.example.org", response="da2f40487bb63329105222dab911d9bd" Content-Type: application/sdp Content-Disposition: session Content-Length: 240 v=0 o=- 9163509233734166984 5909793187606445082 IN IP4 192.168.0.199 s=- c=IN IP4 22.222.222.222 t=0 0 m=audio 43264 RTP/AVP 9 8 0 3 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtcp:33730 5(6) ERROR: <core> [core/kemi.c:96]: sr_kemi_core_err(): ENUM RESULT 1 :RURI sip:enum-test@sip.nemox.net 5(6) ERROR: <core> [core/kemi.c:96]: sr_kemi_core_err(): ksr_sipdump_event 1--------- sipdump:msg SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 192.168.0.199:40867;rport=40867;branch=z9hG4bKvB942Z25j6t6Q;received=22.222.222.222 From: <sip:myself@sip.example.org>;tag=vmjX7H12KrH1B To: <sip:+437200101011@sip.example.org> Call-ID: 8956e785-1905-123c-24bb-e4aaeae9dd8b CSeq: 62865321 INVITE Authentication-Info: nextnonce="Y9QB/GPUANBJum6LTOLsDnjaSLKc/8o1A1zk1oUtFXzlFe/OfiMEAg==", qop=, rspauth="d9dd065ba472cbc3f8cc4505dbd2ad60", cnonce="", nc= Content-Length: 0 0(1) ALERT: <core> [main.c:774]: handle_sigs(): child process 6 exited by a signal 11 24(25) CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 13 0(1) ALERT: <core> [main.c:777]: handle_sigs(): core was generated ``` The full backtrace is: ``` #0 0x00000000004867e5 in atomic_cmpxchg_int (var=0x0, old=0, new_v=1) at core/mem/../atomic/atomic_x86.h:224 ret = 32663 #1 0x0000000000486831 in futex_get (lock=0x0) at core/mem/../futexlock.h:99 v = 0 i = 1024 #2 0x0000000000490ce5 in dns_hash_get (name=0x7ffe2446dbc0, type=33, h=0x7ffe2446da90, err=0x7ffe2446da7c) at core/dns_cache.c:673 e = 0x0 #3 0x00000000004972a7 in dns_get_entry (name=0x7ffe2446dbc0, type=33) at core/dns_cache.c:2001 h = 608623712 e = 0x0 cname_val = { s = 0x0, len = 5860299 } err = 32766 rec_cnt = 1 __func__ = "dns_get_entry" #4 0x0000000000499289 in dns_srv_get_he (name=0x7ffe2446dbc0, port=0x7ffe2446df1c, flags=0) at core/dns_cache.c:2455 e = 0x2 rr = 0x0 rr_name = { s = 0xa3e33d203 <error: Cannot access memory at address 0xa3e33d203>, len = 1043567768 } he = 0x0 now = 611930531 rr_no = 0 '\000' #5 0x0000000000597aae in no_naptr_srv_sip_resolvehost (name=0x7ffe2446e100, port=0x7ffe2446df1c, proto=0x7f973a751788 "\001") at core/resolve.c:1599 srv_proto_list = {{ proto = 1 '\001', proto_pref = 30 }, { proto = 2 '\002', proto_pref = 20 }, { proto = 4 '\004', proto_pref = 20 }, { proto = 3 '\003', proto_pref = 10 }, { proto = 0 '\000', proto_pref = 0 }, { proto = 13 '\r', proto_pref = 1 }, { proto = 80 'P', proto_pref = 319 }} he = 0x0 ip = 0x0 srv_name = { s = 0x929320 <tmp_srv> "_sip._udp.sip.nemox.net", len = 23 } tmp_srv = "_sip._udp.sip.nemox.net", '\000' <repeats 232 times> i = 0 list_len = 4 __func__ = "no_naptr_srv_sip_resolvehost" #6 0x0000000000598333 in naptr_sip_resolvehost (name=0x7ffe2446e100, port=0x7ffe2446df1c, proto=0x7f973a751788 "\001") at core/resolve.c:1675 he = 0x0 ip = 0x0 tmp = "sip.nemox.net", '\000' <repeats 242 times> l = 0x0 naptr_head = 0x0 n_proto = 0 '\000' srv_name = { s = 0x7f97390fee12 <sr_kemi_lua_exec_func_514> "UH\211\345H\203\354\020H\211}\370H\213E\370\276\002\002", len = 1051642410 } tried_bmp = 0 origproto = 0 '\000' __func__ = "naptr_sip_resolvehost" #7 0x00000000005983c6 in _sip_resolvehost (name=0x7ffe2446e100, port=0x7ffe2446df1c, proto=0x7f973a751788 "\001") at core/resolve.c:1707 res = 0x0 #8 0x000000000049943c in dns_srv_sip_resolvehost (name=0x7ffe2446e100, port=0x7ffe2446df1c, proto=0x7f973a751788 "\001") at core/dns_cache.c:2516 he = 0x7f9739119c91 <luaD_callnoyield+449> ip = 0x7f97390fca97 <sr_kemi_lua_exec_func_221> tmp = '\000' <repeats 255 times> srv_name = { s = 0x1a67740 "\020h\247\001", len = 0 } srv_proto = 0 '\000' __func__ = "dns_srv_sip_resolvehost" #9 0x000000000049b3de in dns_sip_resolvehost (name=0x7ffe2446e100, port=0x7ffe2446df1c, proto=0x7f973a751788 "\001") at core/dns_cache.c:2738 No locals. #10 0x000000000059846b in sip_hostport2su (su=0x7f973a751700, name=0x7ffe2446e100, port=5060, proto=0x7f973a751788 "\001") at core/resolve.c:1727 he = 0x7f973e33d2be __func__ = "sip_hostport2su" #11 0x00007f9739efdff0 in uri2dst2 (dns_h=0x7f973a751888, dst=0x7f973a7516f8, force_send_socket=0x0, sflags=..., uri=0x7f973e3390d0, proto=0) at /git/voip/kamailio/src/modules/tm/ut.h:308 parsed_uri = { user = { s = 0x7f973e33d2b4 "enum-test(a)sip.nemox.net", len = 9 }, passwd = { s = 0x0, len = 0 }, host = { s = 0x7f973e33d2be "sip.nemox.net", len = 13 }, port = { s = 0x0, len = 0 }, params = { s = 0x0, len = 0 }, sip_params = { s = 0x0, len = 0 }, headers = { s = 0x0, len = 0 }, port_no = 0, proto = 0, type = SIP_URI_T, flags = 0, transport = { s = 0x0, len = 0 }, ttl = { s = 0x0, len = 0 }, user_param = { s = 0x0, len = 0 }, maddr = { s = 0x0, len = 0 }, method = { s = 0x0, len = 0 }, lr = { s = 0x0, len = 0 }, r2 = { s = 0x0, len = 0 }, gr = { s = 0x0, len = 0 }, transport_val = { s = 0x0, len = 0 }, ttl_val = { s = 0x0, len = 0 }, user_param_val = { s = 0x0, len = 0 }, maddr_val = { s = 0x0, len = 0 }, method_val = { s = 0x0, len = 0 }, lr_val = { s = 0x0, len = 0 }, r2_val = { s = 0x0, len = 0 }, gr_val = { s = 0x0, len = 0 } } uri_proto = PROTO_NONE host = 0x7ffe2446e100 ip_found = 0 to = { s = { sa_family = 57744, sa_data = "F$\376\177\000\000\211\216\0169\227\177\000" }, sin = { sin_family = 57744, sin_port = 9286, sin_addr = { s_addr = 32766 }, sin_zero = "\211\216\0169\227\177\000" }, sin6 = { sin6_family = 57744, sin6_port = 9286, sin6_flowinfo = 32766, sin6_addr = { __in6_u = { __u6_addr8 = "\211\216\0169\227\177\000\000\001\000\000\000\000\000\000", __u6_addr16 = {36489, 14606, 32663, 0, 1, 0, 0, 0}, __u6_addr32 = {957255305, 32663, 1, 0} } }, sin6_scope_id = 1042640912 }, sas = { ss_family = 57744, __ss_padding = "F$\376\177\000\000\211\216\0169\227\177\000\000\001\000\000\000\000\000\000\000\020p%>\227\177\000\000\260\340F$\376\177\000\000\304\311K", '\000' <repeats 37 times>, "\020;\v:\227\177\000\000\360\2153>\227\177\000\000Px\246\001\000\000\000\000\230\2243>\227\177\000\000\002\000\000\000\000\000\000", __ss_align = 27947488 } } err = 32766 __func__ = "uri2dst2" #12 0x00007f9739f00878 in prepare_new_uac (t=0x7f973a751408, i_req=0x7f973e338df0, branch=0, uri=0x7ffe2446e490, path=0x7ffe2446e470, next_hop=0x7f973e3390d0, fsocket=0x0, snd_flags=..., fproto=0, flags=2, instance=0x7ffe2446e460, ruid=0x7ffe2446e450, location_ua=0x7ffe2446e440) at t_fwd.c:447 shbuf = 0x0 add_rm_backup = 0x7f973e33b288 body_lumps_backup = 0x0 parsed_uri_bak = { user = { s = 0x7f973e33a634 "enum-test(a)sip.nemox.net", len = 9 }, passwd = { s = 0x0, len = 0 }, host = { s = 0x7f973e33a63e "sip.nemox.net", len = 13 }, port = { s = 0x0, len = 0 }, params = { s = 0x0, len = 0 }, sip_params = { s = 0x0, len = 0 }, headers = { s = 0x0, len = 0 }, port_no = 0, proto = 0, type = SIP_URI_T, flags = 0, transport = { s = 0x0, len = 0 }, ttl = { s = 0x0, len = 0 }, user_param = { s = 0x0, len = 0 }, maddr = { s = 0x0, len = 0 }, method = { s = 0x0, len = 0 }, lr = { s = 0x0, len = 0 }, r2 = { s = 0x0, len = 0 }, gr = { s = 0x0, len = 0 }, transport_val = { s = 0x0, len = 0 }, ttl_val = { s = 0x0, len = 0 }, user_param_val = { s = 0x0, len = 0 }, maddr_val = { s = 0x0, len = 0 }, method_val = { s = 0x0, len = 0 }, lr_val = { s = 0x0, len = 0 }, r2_val = { s = 0x0, len = 0 }, gr_val = { s = 0x0, len = 0 } } ret = -1 len = 32663 parsed_uri_ok_bak = 1 free_new_uri = 1 msg_uri_bak = { s = 0x7f973e33a630 "sip:enum-test@sip.nemox.net", len = 27 } dst_uri_bak = { s = 0x0, len = 0 } dst_uri_backed_up = 1 path_bak = { s = 0x0, len = 0 } free_path = 1 instance_bak = { s = 0x0, len = 0 } free_instance = 1 ruid_bak = { s = 0x0, len = 0 } free_ruid = 1 ua_bak = { s = 0x0, len = 0 } free_ua = 1 backup_route_type = 1 test_dst = 23 fwd_snd_flags_bak = { f = 0, blst_imask = 0 } rpl_snd_flags_bak = { f = 1, blst_imask = 0 } force_send_socket_bak = 0x0 dst = 0x7f973a7516f8 ctx = { rec_lev = 0, run_flags = 0, last_retcode = 0, jmp_env = {{ __jmpbuf = {140729507046528, 107383054981, 140729507046336, 7983668, 140729507046712, 140729507046688, 0, 0}, __mask_was_saved = 0, __saved_mask = { __val = {0, 0, 0, 0, 1016, 2510101137099545603, 12909040900923746448, 140729507046448, 7983053, 3689621524717335394, 0, 140729507046488, 140729507046688, 8, 8872581, 4179003179399} } }} } bctx = 0x0 keng = 0x913440 <_sr_kemi_eng_list> __func__ = "prepare_new_uac" #13 0x00007f9739f058f0 in add_uac (t=0x7f973a751408, request=0x7f973e338df0, uri=0x7f973e3390d0, next_hop=0x7f973e3390d0, path=0x7f973e339498, proxy=0x0, fsocket=0x0, snd_flags=..., proto=0, flags=2, instance=0x7f973e3394a8, ruid=0x7f973e3394c0, location_ua=0x7f973e3394d0) at t_fwd.c:814 ret = 0 branch = 0 __func__ = "add_uac" #14 0x00007f9739f0f73f in t_forward_nonack (t=0x7f973a751408, p_msg=0x7f973e338df0, proxy=0x0, proto=0) at t_fwd.c:1694 branch_ret = 0 lowest_ret = -1 added_branches = 0 first_branch = 0 i = 32766 t_invite = 0x7f973e33c570 success_branch = 608627136 try_new = 1 lock_replies = 939792 backup_bflags = 0 obranch = { uri = { s = 0x1f600000000 <error: Cannot access memory at address 0x1f600000000>, len = 27594632 }, dst_uri = { s = 0x1 <error: Cannot access memory at address 0x1>, len = 27947488 }, q = 27687040, path = { s = 0x7f97390fca97 <sr_kemi_lua_exec_func_221> "UH\211\345H\203\354\020H\211}\370H\213E\370\276", <incomplete sequence \335>, len = 608627072 }, flags = 972537629, force_socket = 0x1, ruid = { s = 0x7ffe2446e950 "", len = 608627120 }, instance = { s = 0x6400000001 <error: Cannot access memory at address 0x6400000001>, len = 1043566064 }, location_ua = { s = 0x7f973a751408 "p\344\032:\227\177", len = 8388608 }, otcpid = 7449488 } __func__ = "t_forward_nonack" #15 0x00007f9739ef6bc5 in t_relay_to (p_msg=0x7f973e338df0, proxy=0x0, proto=0, replicate=0) at t_funcs.c:332 ret = 0 new_tran = 1 t = 0x7f973a751408 dst = { send_sock = 0x7ffe2446eb80, to = { s = { sa_family = 50040, sa_data = "3>\227\177\000\000\000\000\000\000\000\000\000" }, sin = { sin_family = 50040, sin_port = 15923, sin_addr = { s_addr = 32663 }, sin_zero = "\000\000\000\000\000\000\000" }, sin6 = { sin6_family = 50040, sin6_port = 15923, sin6_flowinfo = 32663, sin6_addr = { __in6_u = { __u6_addr8 = "\000\000\000\000\000\000\000\000\020p%>\227\177\000", __u6_addr16 = {0, 0, 0, 0, 28688, 15909, 32663, 0}, __u6_addr32 = {0, 0, 1042640912, 32663} } }, sin6_scope_id = 27687040 }, sas = { ss_family = 50040, __ss_padding = "3>\227\177\000\000\000\000\000\000\000\000\000\000\020p%>\227\177\000\000\200x\246\001\000\000\000\000\320\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\300c\252\001\000\000\000\000\200x\246\001\000\000\000\000\360\273\0179\227\177\000\000\200\353F$\376\177\000\000\257\363G\000\000\000\000\000\000\000\000\000S\003\000\000\360\2153>\227\177", '\000' <repeats 14 times>, "\022\000\000", __ss_align = 140287560368784 } }, id = 1043579664, send_flags = { f = 32663, blst_imask = 0 }, proto = 0 '\000', proto_pad0 = 0 '\000', proto_pad1 = 0 } port = 0 host = { s = 0x0, len = 1043579608 } comp = 0 __func__ = "t_relay_to" #16 0x00007f9739f48a33 in _w_t_relay_to (p_msg=0x7f973e338df0, proxy=0x0, force_proto=0) at tm.c:1764 t = 0x7ffe2446ec30 res = 3 __func__ = "_w_t_relay_to" #17 0x00007f9739f51dec in ki_t_relay (msg=0x7f973e338df0) at tm.c:2917 No locals. #18 0x00007f97390eb94c in sr_kemi_lua_exec_func_ex (L=0x1a50f88, ket=0x7f9739ff5be0 <tm_kemi_exports>, pdelta=0) at app_lua_api.c:1022 i = 1 argc = 0 ret = 1 fname = 0x7f9739ff5bf0 <tm_kemi_exports+16> mname = 0x7f9739ff5be0 <tm_kemi_exports> vps = {{ n = 27739704, s = { s = 0x1a74638 "ksr_failure_manage", len = 18 } }, { n = 0, s = { s = 0x0, len = 0 } }, { n = 0, s = { s = 0x0, len = 0 } }, { n = 0, s = { s = 0x0, len = 0 } }, { n = 0, s = { s = 0x0, len = 0 } }, { n = 0, s = { s = 0x0, len = 0 } }} env_L = 0x7f9739175a00 <_sr_L_env> xret = 0x7f973a047580 <_sr_kemi_kx_xval> __func__ = "sr_kemi_lua_exec_func_ex" #19 0x00007f97390f337e in sr_kemi_lua_exec_func (L=0x1a50f88, eidx=221) at app_lua_api.c:1706 ket = 0x7f9739ff5be0 <tm_kemi_exports> ret = 1 tvb = { tv_sec = 0, tv_usec = 0 } tve = { tv_sec = 0, tv_usec = 0 } tz = { tz_minuteswest = 1052892288, tz_dsttime = 32663 } tdiff = 27594832 dinfo = { event = 1043568344, name = 0x7f973e339980 <incomplete sequence \350>, namewhat = 0x7ffe2446f03e "", what = 0x3000000018 <error: Cannot access memory at address 0x3000000018>, source = 0x7ffe2446efa0 "\200x\246\001", srclen = 140729507049184, currentline = 8989040, linedefined = 0, lastlinedefined = 73, nups = 0 '\000', nparams = 0 '\000', isvararg = 0 '\000', istailcall = 0 '\000', ftransfer = 4176, ntransfer = 421, short_src = "\000\000\000\000\004\000\000\000\000\000\000\000I\000\000\000\000\000\000\000\204\275\256>\227\177\000\000\300\a\000\000\000\000\000\000@\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000P\020\245\001\000\000\000", i_ci = 0x1a50f88 } __func__ = "sr_kemi_lua_exec_func" #20 0x00007f97390fcab4 in sr_kemi_lua_exec_func_221 (L=0x1a50f88) at app_lua_kemi_export.c:1813 No locals. #21 0x00007f97391193c1 in luaD_precall () from /var/lib/containers/storage/overlay/1ba9d537e5be2b3a47b220bd68cdb6646cd0a1f4ebb83a234c8bcc2324ca5f3f/merged/lib64/kamailio/modules/app_lua.so No symbol table info available. #22 0x00007f973912d4cb in luaV_execute () from /var/lib/containers/storage/overlay/1ba9d537e5be2b3a47b220bd68cdb6646cd0a1f4ebb83a234c8bcc2324ca5f3f/merged/lib64/kamailio/modules/app_lua.so No symbol table info available. #23 0x00007f9739119c91 in luaD_callnoyield () from /var/lib/containers/storage/overlay/1ba9d537e5be2b3a47b220bd68cdb6646cd0a1f4ebb83a234c8bcc2324ca5f3f/merged/lib64/kamailio/modules/app_lua.so No symbol table info available. #24 0x00007f973911802a in luaD_rawrunprotected () from /var/lib/containers/storage/overlay/1ba9d537e5be2b3a47b220bd68cdb6646cd0a1f4ebb83a234c8bcc2324ca5f3f/merged/lib64/kamailio/modules/app_lua.so No symbol table info available. #25 0x00007f973911a1e0 in luaD_pcall () from /var/lib/containers/storage/overlay/1ba9d537e5be2b3a47b220bd68cdb6646cd0a1f4ebb83a234c8bcc2324ca5f3f/merged/lib64/kamailio/modules/app_lua.so No symbol table info available. #26 0x00007f97391143df in lua_pcallk () from /var/lib/containers/storage/overlay/1ba9d537e5be2b3a47b220bd68cdb6646cd0a1f4ebb83a234c8bcc2324ca5f3f/merged/lib64/kamailio/modules/app_lua.so No symbol table info available. #27 0x00007f97390e7f0d in app_lua_run_ex (msg=0x7f973e338df0, func=0x7f973914d598 "ksr_request_route", p1=0x0, p2=0x0, p3=0x0, emode=1) at app_lua_api.c:773 n = 0 ret = 0 txt = { s = 0x7ffe2446f520 "\020\370F$\376\177", len = 5783320 } bmsg = 0x0 ltop = 36 __func__ = "app_lua_run_ex" #28 0x00007f9739106f07 in sr_kemi_config_engine_lua (msg=0x7f973e338df0, rtype=1, rname=0x0, rparam=0x0) at app_lua_mod.c:119 ret = -1 __func__ = "sr_kemi_config_engine_lua" #29 0x00000000005048bf in sr_kemi_route (keng=0x913440 <_sr_kemi_eng_list>, msg=0x7f973e338df0, rtype=1, ename=0x0, edata=0x0) at core/kemi.c:3784 sfbk = 0 ret = 1054122048 #30 0x000000000058890a in receive_msg (buf=0x9b22a0 <buf> "INVITE sip:+437200101011@sip.example.org SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.0.199:40867;TH=div;rport;branch=z9hG4bKvB942Z25j6t6Q\r\nMax-Forwards: 69\r\nFrom: <sip:myself@sip.example.org>;tag=vmjX7H12KrH1B\r\nTo: <sip:+437200101011@sip.example.org>\r\nCall-ID: 8956e785-1905-123c-24bb-e4aaeae9dd8b\r\nCSeq: 62865321 INVITE\r\nContact: <sip:myself@sip.example.org>\r\nUser-Agent: calls sofia-sip/1.13.12\r\nAllow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE\r\nSupported: timer, 100rel, replaces, gruu, outbound\r\nProxy-Authorization: Digest username=\"myself\", realm=\"example.int\", nonce=\"Y9QB/GPUANBJum6LTOLsDnjaSLKc/8o1A1zk1oUtFXzlFe/OfiMEAg==\", algorithm=MD5, uri=\"sip:+437200101011@sip.example.org\", response=\"da2f40487bb63329105222dab911d9bd\"\r\nContent-Type: application/sdp\r\nContent-Disposition: session\r\nContent-Length: 240\r\nTH: dih\r\n\r\nv=0\r\no=- 9163509233734166984 5909793187606445082 IN IP4 192.168.0.199\r\ns=-\r\nc=IN IP4 22.222.222.222\r\nt=0 0\r\nm=audio 43264 RTP/AVP 9 8 0 3\r\na=rtpmap:9 G722/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:3 GSM/8000\r\na=rtcp:33730\r\n", len=1093, rcv_info=0x7ffe2446fae0) at core/receive.c:502 msg = 0x7f973e338df0 ctx = { rec_lev = 256, run_flags = 16777216, last_retcode = 0, jmp_env = {{ __jmpbuf = {1099511627776, 512, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = { __val = {0, 0, 0, 0, 0, 0, 0, 4294967296, 1225543208507932942, 33554432, 3298534883584, 72057594037928192, 72057594037927936, 1099511627776, 512, 0} } }} } bctx = 0x0 ret = 0 tvb = { tv_sec = 0, tv_usec = 0 } tve = { tv_sec = 0, tv_usec = 0 } diff = 0 inb = { s = 0x9b22a0 <buf> "INVITE sip:+437200101011@sip.example.org SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.0.199:40867;TH=div;rport;branch=z9hG4bKvB942Z25j6t6Q\r\nMax-Forwards: 69\r\nFrom: <sip:myself@sip.example.org>;tag=vmjX7H12KrH1B\r\nTo: <sip:+437200101011@sip.example.org>\r\nCall-ID: 8956e785-1905-123c-24bb-e4aaeae9dd8b\r\nCSeq: 62865321 INVITE\r\nContact: <sip:myself@sip.example.org>\r\nUser-Agent: calls sofia-sip/1.13.12\r\nAllow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE\r\nSupported: timer, 100rel, replaces, gruu, outbound\r\nProxy-Authorization: Digest username=\"myself\", realm=\"example.int\", nonce=\"Y9QB/GPUANBJum6LTOLsDnjaSLKc/8o1A1zk1oUtFXzlFe/OfiMEAg==\", algorithm=MD5, uri=\"sip:+437200101011@sip.example.org\", response=\"da2f40487bb63329105222dab911d9bd\"\r\nContent-Type: application/sdp\r\nContent-Disposition: session\r\nContent-Length: 240\r\nTH: dih\r\n\r\nv=0\r\no=- 9163509233734166984 5909793187606445082 IN IP4 192.168.0.199\r\ns=-\r\nc=IN IP4 22.222.222.222\r\nt=0 0\r\nm=audio 43264 RTP/AVP 9 8 0 3\r\na=rtpmap:9 G722/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:3 GSM/8000\r\na=rtcp:33730\r\n", len = 1093 } netinfo = { data = { s = 0x0, len = 0 }, bufsize = 0, rcv = 0x0, dst = 0x0 } keng = 0x913440 <_sr_kemi_eng_list> evp = { data = 0x7ffe2446f630, obuf = { s = 0x0, len = 0 }, rcv = 0x7ffe2446fae0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0 } cidlockidx = 0 cidlockset = 0 errsipmsg = 0 exectime = 0 __func__ = "receive_msg" #31 0x00000000006cad81 in udp_rcv_loop () at core/udp_server.c:544 len = 1077 buf = "INVITE sip:+437200101011@sip.example.org SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.0.199:40867;TH=div;rport;branch=z9hG4bKvB942Z25j6t6Q\r\nMax-Forwards: 69\r\nFrom: <sip:myself@sip.example.org>;tag=vmjX7H12KrH1B\r\nTo: <sip:+437200101011@sip.example.org>\r\nCall-ID: 8956e785-1905-123c-24bb-e4aaeae9dd8b\r\nCSeq: 62865321 INVITE\r\nContact: <sip:myself@sip.example.org>\r\nUser-Agent: calls sofia-sip/1.13.12\r\nAllow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE\r\nSupported: timer, 100rel, replaces, gruu, outbound\r\nProxy-Authorization: Digest username=\"myself\", realm=\"example.int\", nonce=\"Y9QB/GPUANBJum6LTOLsDnjaSLKc/8o1A1zk1oUtFXzlFe/OfiMEAg==\", algorithm=MD5, uri=\"sip:+437200101011@sip.example.org\", response=\"da2f40487bb63329105222dab911d9bd\"\r\nContent-Type: application/sdp\r\nContent-Disposition: session\r\nContent-Length: 240\r\nTH: dih\r\n\r\nv=0\r\no=- 9163509233734166984 5909793187606445082 IN IP4 192.168.0.199\r\ns=-\r\nc=IN IP4 22.222.222.222\r\nt=0 0\r\nm=audio 43264 RTP/AVP 9 8 0 3\r\na=rtpmap:9 G722/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:3 GSM/8000\r\na=rtcp:33730\r\n", '\000' <repeats 64442 times> tmp = 0x13a3d9090 <error: Cannot access memory at address 0x13a3d9090> fromaddr = 0x7f973e338ba8 fromaddrlen = 16 rcvi = { src_ip = { af = 2, len = 4, u = { addrl = {2576512599, 0}, addr32 = {2576512599, 0, 0, 0}, addr16 = {30295, 39314, 0, 0, 0, 0, 0, 0}, addr = "Wv\222\231", '\000' <repeats 11 times> } }, dst_ip = { af = 2, len = 4, u = { addrl = {1317948560, 0}, addr32 = {1317948560, 0, 0, 0}, addr16 = {19600, 20110, 0, 0, 0, 0, 0, 0}, addr = "\220L\216N", '\000' <repeats 11 times> } }, src_port = 40867, dst_port = 5060, proto_reserved1 = 0, proto_reserved2 = 0, src_su = { s = { sa_family = 2, sa_data = "\237\243Wv\222\231\000\000\000\000\000\000\000" }, sin = { sin_family = 2, sin_port = 41887, sin_addr = { s_addr = 2576512599 }, sin_zero = "\000\000\000\000\000\000\000" }, sin6 = { sin6_family = 2, sin6_port = 41887, sin6_flowinfo = 2576512599, sin6_addr = { __in6_u = { __u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0} } }, sin6_scope_id = 0 }, sas = { ss_family = 2, __ss_padding = "\237\243Wv\222\231", '\000' <repeats 111 times>, __ss_align = 0 } }, bind_address = 0x7f973e2e7768, rflags = 0, proto = 1 '\001', proto_pad0 = 0 '\000', proto_pad1 = 0 } evp = { data = 0x0, obuf = { s = 0x0, len = 0 }, rcv = 0x0, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0 } printbuf = "\000\000\000\000\000\000\000\000\270\003G$\376\177\000\000\370\235\216\000\000\000\000\000@\240\324>\227\177\000\000\340\370F$\376\177\000\000D\204\0209\227\177\000\000\370\235\216\000\000\000\000\000@\240\324>\005\000\000\000\260\371F$\376\177\000\000\263\372b", '\000' <repeats 57 times>, "\005\000\000\000P\2210>\227\177", '\000' <repeats 90 times>, "\274\202=:\227\177\000\000\000\000\000\000\004\000\000\000\260-\205\000\000\000\000\000\370\235\216\000\000\000\000\000@\240\324>\005\000\000\000\200\372F$\376\177\000\000\263\372b", '\000' <repeats 13 times>, "0^\235\000\000\000\000\000\000^\235\000\000\000\000\000\230g\235\000\000\000\000\000K\306[\302!\307S\354\230\"7(ɘR\354\263ƚ\316\005\000\000\000\350\2260>\227\177\000\000 ^\235\000\000\000\000\000\230g\235\000\000\000\000\000\031\216\n\274\001\000\000\000@h\235\000\000\000\000\000P\372F$\376\177\000\000\240h\235\000\000\000\000\000\240g\235\000\000\000\000\000\000^\235\000\000\000\000\000p\372F$\376\177\000\000\235\275y\000\000\000\000\000p\372F$\376\177\000\000\274\202=:\227\177\000\000\000\000\000\000\000\000\000\000\270\003G$\376\177\000\000\370\235\216\000\000\000\000\000@\240\324>\227\177\000\0000\373F$\376\177\000\000\250\002c\000\000\000\000\000\320\372F$\376\177\000\000\213\305y\000\000\000\000" i = -1 j = 41600 l = 5 __func__ = "udp_rcv_loop" #32 0x000000000042d3af in main_loop () at main.c:1722 i = 4 pid = 0 si = 0x7f973e2e7768 si_desc = "udp receiver child=4 sock=111.11.111.11:5060\000\000d\000p\375F$\376\177\000\000\000\000\000\000\000\000\000\000\200\375F$\376\177\000\000s\300\3229\227\177\000\000\020\376F$\376\177\000\000\v\006\3239\227\177\000\000`\375F$\376\177\000\0001\rp\000\000\000\000\000\320/\203\000\000\000\000\000\001\000\000\000k\000\000" nrprocs = 8 woneinit = 1 __func__ = "main_loop" #33 0x00000000004390be in main (argc=3, argv=0x7ffe24470398) at main.c:3078 cfg_stream = 0x1931380 c = -1 r = 0 tmp = 0x0 tmp_len = 0 port = 0 proto = 0 ahost = 0x0 aport = 0 options = 0x8081f8 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 3092184453 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 2 n_lst = 0x0 p = 0x0 st = { st_dev = 65025, st_ino = 3424267, st_nlink = 3, st_mode = 16895, st_uid = 65534, st_gid = 65534, __pad0 = 0, st_rdev = 0, st_size = 4096, st_blksize = 4096, st_blocks = 8, st_atim = { tv_sec = 1674835346, tv_nsec = 294486590 }, st_mtim = { tv_sec = 1674837962, tv_nsec = 574996365 }, st_ctim = { tv_sec = 1674837962, tv_nsec = 574996365 }, __glibc_reserved = {0, 0, 0} } tbuf = "D\377F$\376\177", '\000' <repeats 18 times>, "hq\247>\227\177\000\000\200\374\245>\227\177\000\000\020\000G$\376\177\000\000\b\000G$\376\177\000\000W\301\000\000\000\000\000\000``\321>\227\177\000\000\005", '\000' <repeats 23 times>, "\210\266\324>\227\177\000\000\000p\321>\227\177\000\000\342z\321>\227\177\000\000f\024\322>\227\177\000\000\260إ>", '\000' <repeats 12 times>, "\260Z\321>\227\177\000\0008^\321>\227\177\000\000\344U0\000\000\000\000\000hq\247>\227\177\000\000\220\000G$\376\177\000\000\b\000G$\376\177\000\000\340h\321>\227\177\000\000/\v\322>\227\177\000\000\004\000\000\000\000\000\000\000\340h\321>\227\177\000\000\001", '\000' <repeats 15 times>, "\001\000\000\000\000\000\000\000\260Z\321>\227\177\000\000\260Z\321>\227\177\000\000\001\000\000\000\003\000\000\000\020\000G$\376\177\000\0008^\321>\227\177\000\000\000\000\000\000\000\000\000\000\001", '\000' <repeats 16 times>, "\037G$\376\177\000\000\001\261\324>\227\177\000\000\377\377\377\377\000\000\000\000\330w\321>\227\177\000\000\360\252\324>\227\177\000\0006\027g\n3@\022\000\000\263\324>\227\177\000\000\306\363v\n3@\022\000\005", '\000' <repeats 15 times>, "\260Z\321>\227\177\000\000\017\000\000\000\000\000\000\000\300\321\301>\227\177\000\000\270\003G$\376\177\000\000\370\235\216\000\000\000\000\000@\240\324>\227\177\000\000^n\322>\227\177\000\000\001", '\000' <repeats 15 times>, "\330w\321>\227\177\000\000\340\326\322>\227\177\000\000\000\000\000\000\000\000\000\000\020\003G$\376\177\000\000\003", '\000' <repeats 14 times> option_index = 0 long_options = {{ name = 0x80a91f "help", has_arg = 0, flag = 0x0, val = 104 }, { name = 0x8054cc "version", has_arg = 0, flag = 0x0, val = 118 }, { name = 0x80a924 "alias", has_arg = 1, flag = 0x0, val = 1024 }, { name = 0x80a92a "subst", has_arg = 1, flag = 0x0, val = 1025 }, { name = 0x80a930 "substdef", has_arg = 1, flag = 0x0, val = 1026 }, { name = 0x80a939 "substdefs", has_arg = 1, flag = 0x0, val = 1027 }, { name = 0x80a943 "server-id", has_arg = 1, flag = 0x0, val = 1028 }, { name = 0x80a94d "loadmodule", has_arg = 1, flag = 0x0, val = 1029 }, { name = 0x80a958 "modparam", has_arg = 1, flag = 0x0, val = 1030 }, { name = 0x80a961 "log-engine", has_arg = 1, flag = 0x0, val = 1031 }, { name = 0x80a96c "debug", has_arg = 1, flag = 0x0, val = 1032 }, { name = 0x80a972 "cfg-print", has_arg = 0, flag = 0x0, val = 1033 }, { name = 0x80a97c "atexit", has_arg = 1, flag = 0x0, val = 1034 }, { name = 0x0, has_arg = 0, flag = 0x0, val = 0 }} __func__ = "main" quit ``` 111.11.111.11 is the IP address of the server. 22.222.222.222 is my public IP address. 192.168.0.199 is my address behind NAT. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3350 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3350(a)github.com>

4 23

[kamailio/kamailio] core/resolve: Check dns_cache_init and choose appropriate functions (PR #3858)
by Xenofon Karamanos 04 Jun '24

04 Jun '24

#### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #3350 #### Description  This PR fixes a crash when `dns_cache_init=off`. The issue is described in #3350 and the crash is caused when trying to search in `dns_cache.c` [LOCK_DNS_HASH();](https://github.com/kamailio/kamailio/blob/d4629be286fc6d3…. When `dns_cache_init=off`, the lock is never initialized and when trying to lock it crashes. Per my understanding, when `dns_cache_init=off`, no calls to `dns_cache.c` should be made and instead call the alternative ones from `resolve.c`, since the whole functions are compiled only when USE_DNS_CACHE definition is present. Just a question to clarify, what is the reasoning behind USE_DNS_CACHE definition and a separate `dns_cache_init` parameter? You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3858 -- Commit Summary -- * core/resolve: Check dns_cache_init and choose appropriate functions -- File Changes -- M src/core/resolve.c (16) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3858.patch https://github.com/kamailio/kamailio/pull/3858.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3858 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3858(a)github.com>

3 11

[kamailio/kamailio] rtpengine: multipart content dropped when used read_sdp_pv (Issue #3854)
by sergey-safarov 03 Jun '24

03 Jun '24

### Description When configured `read_sdp_pv` param for rtpengine module, then multipart content dropped in the body. And the message cannot be parsed because ``` Content-Type: multipart/mixed;boundary=level3-boundary ``` But the message body does not have a separator. ### Troubleshooting #### Reproduction To reproduce need to start Kamailio with config file ``` loadmodule "pv.so" loadmodule "ctl.so" loadmodule "corex.so" loadmodule "sdpops.so" loadmodule "rtpengine.so" modparam("rtpengine", "rtpengine_sock", "udp:localhost:2223") modparam("rtpengine", "read_sdp_pv", "$var(sdp_for_rtpengine)") listen=udp:x.x.x.x:5060 request_route { $var(sdp_for_rtpengine) = $sdp(body); rtpengine_manage("ICE=force"); forward(); } ``` And then send call using `sipp` script ```xml <scenario name="Basic Sipstone UAC">   <send retrans="500"> <![CDATA[ INVITE sip:[service]@example.com:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number] To: sut <sip:[service]@[remote_ip]:[remote_port]> Call-ID: [call_id] CSeq: 1 INVITE Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Type: multipart/mixed;boundary=level3-boundary Content-Length: [len] --level3-boundary Content-Type: application/sdp v=0 o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip] s=- c=IN IP[media_ip_type] [media_ip] t=0 0 m=audio [media_port] RTP/AVP 0 a=rtpmap:0 PCMU/8000 --level3-boundary Content-Type: application/isup;version=ansi Content-Disposition: session;handling=optional \x01\x18\x08\x10\x0a\x03\x06\x0d\x03\x80\x90\xa2\x07\x03\x10\x87\x36\x08\x14\x89 \x0a\x07\x03\x13\x27\x97\x45\x28\x49\xc0\x08\xc0\x03\x10\x65\x41\x17\x88\x67\x3d \x01\x11\xc4\x03\x01\x01\x00\xea\x01\x01\xc7\x01\x20\x01\x0d\x0a --level3-boundary-- ]]> </send> ``` If the `read_sdp_pv` param will be commented in the Kamailio config file, then the resulting message will be properly formatted and have the other multipart media. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3854 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3854(a)github.com>

2 2

[kamailio/kamailio] uac: add reload_delta parameter (PR #3829)
by Tyler Moore 03 Jun '24

03 Jun '24

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description Add support for setting a different RPC reload interval than the reg_gc_interval parameter. This allows the cleanup timer to match the user's re-transmission timeout without constraining RPC reload times to a large interval. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3829 -- Commit Summary -- * uac: add reload_delta parameter -- File Changes -- M src/modules/uac/doc/uac.xml (9) M src/modules/uac/doc/uac_admin.xml (37) M src/modules/uac/uac.c (5) M src/modules/uac/uac_reg.c (5) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3829.patch https://github.com/kamailio/kamailio/pull/3829.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3829 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3829(a)github.com>

3 5

[kamailio/kamailio] possible memory corruption in sipcapture module (Issue #3835)
by Sven Uhlig 03 Jun '24

03 Jun '24

### Description We send HEP3 data to the UDP listener in kamailio. In this HEP3 data, there are SIP requests and replies. We want to route these SIP messages through `request_route` and `onreply_route`. For this, we use the SipCapture module with the following settings: ``` modparam("sipcapture", "db_url", DBURL) modparam("sipcapture", "capture_on", 1) modparam("sipcapture", "hep_capture_on", 1) modparam("sipcapture", "insert_retries", 0) modparam("sipcapture", "insert_retry_timeout", 0) request_route { xlog("L_INFO", "Got new request ($ci) $rm: $si => $Ri\n"); } onreply_route { xlog("L_INFO", "Got new reply ($ci) $rm: $si => $Ri - Reply Code $rs\n"); } ``` In the past (version kamailio 5.1.x - 5.4.x), this worked as expected. From the logs: ``` 2(8) INFO: <script>: Got new request (7xkVDrAWegvcZl-ACaUb1HWHwiCYhAJR) INVITE: 217.116.121.230 => 172.20.21.4 3(9) INFO: <script>: Got new reply (7xkVDrAWegvcZl-ACaUb1HWHwiCYhAJR) INVITE: 172.20.21.4 => 217.116.121.230 - Reply Code 407 ``` Starting with kamailio 5.5.x, some pseudo variables are broken. From the logs: ``` 1(7) INFO: <script>: Got new request (7xkVDrAWegvcZl-ACaUb1HWHwiCYhAJR) INVITE: 217.116.121.230 => 217.116.121 2(8) INFO: <script>: Got new reply (7xkVDrAWegvcZl-ACaUb1HWHwiCYhAJR) INVITE: 172.20.21.4 => 172.20.21.4 3(9) INFO: <script>: ... ``` As you can see, the `$Ri` in the request is wrong. It looks like the first three octets of the `$si` and the fourth octet is missing entirely. And for the reply: - The `$Ri` is the `$si`. - The line is missing the static text `Reply Code`, the actual reply code. - The next log is on the same line (the new line is gone). (In this case, we simply sent a third HEP3 message.) To my untrained eye this looks like possible memory corruption. ### Troubleshooting #### Reproduction 1. Set up a kamailio 5.8.1 using the attached [kamailio.cfg](https://github.com/kamailio/kamailio/files/15161868/kamailio.… `/usr/sbin/kamailio -E -DD -dd -f "/etc/kamailio/kamailio.cfg"` 2. Send the HEP3 data using [heplify](https://github.com/sipcapture/heplify) `./heplify -t pcap -rf "sipcapture-bug.pcap" -hs localhost:9060 -e -eof-exit` #### Debugging Data #### Log Messages see above #### SIP Traffic see attached [sipcapture-bug.pcap](https://github.com/kamailio/kamailio/files/15161698/si… ### Possible Solutions Use kamailio 5.4.x or earlier versions. ### Additional Information When setting `nonsip_hook` = `1`, then the `$hep(...)` pseudo variables look fine. Unfortunately, we don't know how process the SIP messages after that point. ``` modparam("sipcapture", "nonsip_hook", 1) ... event_route[sipcapture:request] { xlog("L_INFO", "version: $hep(version)\n"); xlog("L_INFO", "src_ipv4: $hep(0x003)\n"); xlog("L_INFO", "dst_ipv4: $hep(0x004)\n"); xlog("L_INFO", "src_proto: $hep(0x007)\n"); xlog("L_INFO", "dst_proto: $hep(0x008)\n"); xlog("L_INFO", "proto: $hep(0x00b)\n"); } ``` * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.1 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: compiled with gcc 12.2.0 ``` Also tested with same error: 5.5.x, 5.6.x, 5.7.x * **Operating System**: ``` # lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3835 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3835(a)github.com>

4 12

[kamailio/kamailio] Crash on shutdown after geoip2.reload (Issue #3861)
by Bastian Triller 03 Jun '24

03 Jun '24

### Description Kamailio crashes on shutdown in `geoip2_destroy_pv` in `main process` process if geoip2 database was reloaded.  ### Troubleshooting `libmaxminddb.so.0` uses `calloc()` internally to allocate memory for metadata languages and descriptions. On reload via e.g. `ctl` metadata memory is allocated in `ctl` process but `main process` tries to cleanup it. #### Reproduction Load `geoip2` module ``` loadmodule "geoip2.so" modparam("geoip2", "path", "/path/to/your/geolite2.mmdb") ``` Reload database and stop/restart Kamailio ``` kamcmd geoip2.reload service kamailio restart ```  #### Debugging Data ``` (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007f117bc59e8f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 #2 0x00007f117bc0afb2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007f117bbf5472 in __GI_abort () at ./stdlib/abort.c:79 #4 0x00007f117bc4e430 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f117bd68459 "%s\n") at ../sysdeps/posix/libc_fatal.c:155 #5 0x00007f117bc637aa in malloc_printerr (str=str@entry=0x7f117bd660b1 "free(): invalid pointer") at ./malloc/malloc.c:5660 #6 0x00007f117bc65534 in _int_free (av=<optimized out>, p=<optimized out>, have_lock=have_lock@entry=0) at ./malloc/malloc.c:4435 #7 0x00007f117bc67e8f in __GI___libc_free (mem=<optimized out>) at ./malloc/malloc.c:3385 #8 0x00007f1158e6e454 in free_languages_metadata (mmdb=0x7f11592db390) at ./src/maxminddb.c:1860 #9 free_mmdb_struct (mmdb=0x7f11592db390) at ./src/maxminddb.c:1843 #10 0x00007f1158e708a5 in MMDB_close (mmdb=<optimized out>) at ./src/maxminddb.c:1803 #11 0x00007f1158e7ebc9 in geoip2_destroy_pv () at ./src/modules/geoip2/geoip2_pv.c:567 #12 0x000056094fd5f743 in destroy_modules () at core/sr_module.c:881 #13 0x000056094fbb7910 in cleanup (show_status=show_status@entry=1) at ./src/main.c:587 #14 0x000056094fbb86ad in shutdown_children (show_status=show_status@entry=1, sig=15) at ./src/main.c:735 #15 0x000056094fbb932b in handle_sigs () at ./src/main.c:835 #16 0x000056094fbbf1e9 in main_loop () at ./src/main.c:2002 #17 0x000056094fbb353c in main (argc=<optimized out>, argv=<optimized out>) at ./src/main.c:3256 ``` ``` (gdb) f 8 #8 0x00007f1158e6e454 in free_languages_metadata (mmdb=0x7f11592db390) at ./src/maxminddb.c:1860 1860 FREE_AND_SET_NULL(mmdb->metadata.languages.names); (gdb) p *mmdb $1 = {flags = 1, filename = 0x0, file_size = 652795, file_content = 0x7f1158dcd000 <error: Cannot access memory at address 0x7f1158dcd000>, data_section = 0x7f1158e6c430 <error: Cannot access memory at address 0x7f1158e6c430>, data_section_size = 459, metadata_section = 0x7f1158e6c546 <error: Cannot access memory at address 0x7f1158e6c546>, metadata_section_size = 181, full_record_byte_size = 6, depth = 32, ipv4_start_node = {netmask = 0, node_value = 0}, metadata = {node_count = 108720, record_size = 24, ip_version = 4, database_type = 0x0, languages = {count = 1, names = 0x560951ca6250}, binary_format_major_version = 2, binary_format_minor_version = 0, build_epoch = 1648557301, description = {count = 1, descriptions = 0x560951ca5470}}} (gdb) f 9 #9 free_mmdb_struct (mmdb=0x7f11592db390) at ./src/maxminddb.c:1843 1843 free_languages_metadata(mmdb); (gdb) f 10 #10 0x00007f1158e708a5 in MMDB_close (mmdb=<optimized out>) at ./src/maxminddb.c:1803 1803 void MMDB_close(MMDB_s *const mmdb) { free_mmdb_struct(mmdb); } (gdb) f 11 #11 0x00007f1158e7ebc9 in geoip2_destroy_pv () at ./src/modules/geoip2/geoip2_pv.c:567 567 MMDB_close(_handle_GeoIP); ```  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` /usr/sbin/kamailio -V version: kamailio 5.8.1 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ``` * **Operating System**:  ``` cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3861 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3861(a)github.com>

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev May 2024