sr-dev May 2020

sr-dev@lists.kamailio.org

24 participants
394 discussions

[kamailio/kamailio] app_java.so: undefined symbol: JNI_CreateJavaVM please help (#1969)
by xevilstar 11 Aug '20

11 Aug '20

### Description  ### Troubleshooting #### Reproduction  #### 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` ``` (paste your output here) ``` * **Operating System**:  ``` (paste your output here) ``` -- 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/1969

4 29

[kamailio/kamailio] t_set_fr only works with UDP (#1966)
by Boden Garman 11 Aug '20

11 Aug '20

4 7

[kamailio/kamailio] RPM repos at https://rpm.kamailio.org (#2084)
by Daniel-Constantin Mierla 11 Aug '20

11 Aug '20

Build own repositories for RPM packages for various distros: CentOS, RedHate, OpenSuse ... -- 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/2084

8 37

[kamailio/kamailio] rtpengine module is not retrying for rtpengine_offer. retry is working for rtpengine_answer and rtpengine_delete (#1696)
by Surendra Tiwari 11 Aug '20

11 Aug '20

### Description we are using rtpengine with kamailio [KSR-LUA]. kamailio sending the rtpengine_offer to rtpengine. If kamailio didn't get the response from the rtpengine then it's not retrying . for rtpengine_answer and rtpengine_delete retry is working pretty good. we are using following rtpengine configuration # ----- rtpengine params ----- modparam("rtpengine", "db_url", DBURL) modparam("rtpengine", "table_name" , "rtpengine") modparam("rtpengine", "rtpengine_allow_op", 1) modparam("rtpengine", "queried_nodes_limit", 4) modparam("rtpengine", "rtpengine_retr", 2) modparam("rtpengine", "rtp_inst_pvar", "$avp(RTP_INSTANCE)") modparam("rtpengine", "setid_default", 1) modparam("rtpengine", "rtpengine_tout_ms", 400)  ### Troubleshooting #### Reproduction This issue can be reproduced by above configuration. and need to use rtpengine_offer,rtpengine_answer and rtpengine_delete with ksr lua routing.  #### 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` ``` version: kamailio 5.1.4 (x86_64/linux) a1df59 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: a1df59 compiled on 06:23:23 Oct 30 2018 with gcc 4.8.4 ``` * **Operating System**:  ``` root@ip-172-31-4-160:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty root@ip-172-31-4-160:~# uname -a Linux ip-172-31-4-160 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27 10:45:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux ``` -- 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/1696

3 4

[kamailio/kamailio] Active dialog stats stays static on a passive kamailio node that replicates dialogs via DMQ (#1692)
by Joel Serrano 11 Aug '20

11 Aug '20

### Description In a setup with 2 kamailios in active/passive with a virtual IP that failovers between them: sbc01 (active) is handling calls. sbc02 (passive) is started, and does an initial dialog sync via DMQ ``` root@sbc01:~# kamctl rpc stats.get_statistics all | grep dialog "dialog:active_dialogs = 39", "dialog:early_dialogs = 2", "dialog:expired_dialogs = 0", "dialog:failed_dialogs = 583", "dialog:processed_dialogs = 2527", root@sbc01:~# ``` ``` root@sbc02:/etc/kamailio# kamctl rpc stats.get_statistics all | grep dialog "dialog:active_dialogs = 39", "dialog:early_dialogs = 0", "dialog:expired_dialogs = 0", "dialog:failed_dialogs = 0", "dialog:processed_dialogs = 0", root@sbc02:/etc/kamailio# ``` >From that point onwards, as long as sbc01 stays as active, sbc02 stays as passive, and no restarts occur anywhere, the values for `dialog` metrics in sbc02 will not change and remain as they are, in the previous example, active_dialogs would remain as 39. ### Troubleshooting This was discovered during some tests from #1591 #### Reproduction Setup 2 kamailio instances that replicate dialogs via DMQ. 1- On Kamailio1 put some traffic to have some active dialogs (must call `dlg_manage()` in routing script for these test calls) 2- Start Kamailio2 3- Compare output of: `kamcmd stats.get_statistics dialog:` on both nodes. 4- Alter the amount of active dialogs on Kamailio1 (either end some or create new ones). 5- Repeat step 3. Kamailio1 --> Step5 will have different values from Step3. Kamailio2 --> Step5 will have exactly the same values from Step3. ### Possible Solutions `dialog:active_dialogs` should remain as 0 on Kamailio2, as technically there are no dialogs being handled by that server, it only has information of replicated dialogs and those stats are available in the `dlg.stats_active` metric. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` # kamailio -V version: kamailio 5.2.0-pre1 (x86_64/linux) 2ecf60-dirty flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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: 2ecf60 -dirty compiled with gcc 6.3.0 ``` * **Operating System**:  ``` root@sbc02:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 9.5 (stretch) Release: 9.5 Codename: stretch root@sbc02:~# uname -a Linux sbc02 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux root@sbc02:~# ``` -- 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/1692

2 2

[kamailio/kamailio] t_forward_nonack not decoding/unescaping URI (#2255)
by Julien Chavanton 10 Aug '20

10 Aug '20

### Description SIP OPTION relayed using `t_forward_nonack()` not being URI decoded  ### Troubleshooting #### Reproduction register with PATH and use SIP OPTION keep alive or simply send relay a SIP OPTIONS with a route. #### Debugging Data  ```#1 0x00007fa3067a998f in t_forward_nonack (t=0x7fa3246fce88, p_msg=0x7fa3885aa1c0, proxy=0x0, proto=0) at t_fwd.c:1729 1729 raise(SIGSEGV); (gdb) l 1724 ser_error=MIN_int(lowest_ret, E_CFG); 1725 return -1; 1726 } 1727 if(lowest_ret!=E_CFG) { 1728 LM_ERR("failure to add branches\n"); 1729 raise(SIGSEGV); << raising exception to get the coredump 1730 } 1731 ser_error=lowest_ret; 1732 return lowest_ret; 1733 } ``` #### Log Messages ``` 4(34) ERROR: tm [ut.h:245]: uri2dst2(): bad_uri: sip:247.25.169.51:52307%3Btransport%3Dtls 4(34) ERROR: tm [t_fwd.c:1728]: t_forward_nonack(): failure to add branches ``` ### Possible Solutions This patch can fix the problem from the routing script : ``` if (is_method("OPTIONS") && uri!=myself) { $var(path_uri) = $(hdr(Route){re.subst,/<(.*)>/\1/}); if (defined $(var(path_uri){uri.params}) && $(var(path_uri){uri.params}{param.value,received}) != "") { $var(received) = $(var(path_uri){uri.params}{param.value,received}); if ($var(received) =~ "sip:.*:.*") { $du = $var(received); $avp(received) = $(var(path_uri){uri.params}{param.value,received}); avp_subst("$avp(received)", "/%3Btransport%3Dtcp/;transport=tcp/ig"); if ($avp(received) =~ "sip:.*:.*") { $du = $avp(received); } } t_relay(); } ``` ### Additional Information tested on 5.3.2, something changed during 5.3.0.dev, I will try to pin point the commit -- 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/2255

2 14

[kamailio/kamailio] kamailio packages for Ubuntu 20.04 (#2338)
by Henning Westerholt 04 Aug '20

04 Aug '20

It would be great if to deb.kamailio.org new packages for the new Ubuntu 20.04 could be added. -- 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/2338

3 9

[kamailio] Anyone thinking about adding JWT (JSON Web Token) support to Kamailio (#29)
by mading087 24 Jul '20

24 Jul '20

It seems a good idea to support JWT as a new SIP authorization method. Wonder if anyone is interested? Think auth_db would be the best spot to add support for JWT. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/29

12 24

[kamailio/kamailio] set_contact_alias() issue with clients adding it to their Contact (#2308)
by mtryfoss 02 Jul '20

02 Jul '20

I'm using set_contact_alias() to fix nat registrations, in this case with a Bria client. Somehow Bria learns that I'm using this - probably through the Contact in the 200 OK reply of save(). Bria then adds this to the Contact when replying to incoming INVITE. After some time, something happens in the network at client side and the connection gets a new port through the router. Bria does not notice and still sends the old alias-parameter with the port not used anymore. When I'm calling handle_ruri_alias(), Kamailio reads this instead of the actual port and the ACK to 200 OK is sent to a port not used anymore. This can probably be solved by either, in preferred order: - rewrite set_contact_alias() and add_contact_alias() to replace existing alias parameters - regexp remove of alias parameter from Contact of all messages coming from clients - regexp remove of alias parameter from Contact returned by save() Br, Morten -- 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/2308

4 15

[kamailio/kamailio] Intermittent failed assertion in app_python3 (#2335)
by Alex Balashov 09 Jun '20

09 Jun '20

Submitting this on behalf of Jacob Greene, who posted a day or two ago: https://lists.kamailio.org/pipermail/sr-users/2020-May/109315.html Version in production is Debian 9 and Kamailio 5.3.4 from Debian packages: ``` ii kamailio 5.3.4+bpo9 amd64 very fast, dynamic and configurable SIP server ii kamailio-postgres-modules:amd64 5.3.4+bpo9 amd64 PostgreSQL database connectivity module for the Kamailio SIP server ii kamailio-presence-modules:amd64 5.3.4+bpo9 amd64 SIP presence modules for Kamailio ii kamailio-python3-modules:amd64 5.3.4+bpo9 amd64 The app_python3 module for the Kamailio SIP server rc kamailio-xml-modules:amd64 5.2.6+stretch amd64 XML based extensions for Kamailio's Management Interface ``` Anyway, a Kamailio child process periodically exits -- about ten times a day -- with a `SIGABRT` set off by a failed assertion somewhere inside the `app_python3` bureaucracy: ``` (gdb) where #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007f2c2f76042a in __GI_abort () at abort.c:89 #2 0x00007f2c2f757e67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7f2c2892bda8 "PyBytes_Check(pframe->f_code->co_name)", file=file@entry=0x7f2c2892bd9c "apy_kemi.c", line=line@entry=1819, function=function@entry=0x7f2c2892d0b0 "sr_apy_kemi_exec_func") at assert.c:92 #3 0x00007f2c2f757f12 in __GI___assert_fail (assertion=0x7f2c2892bda8 "PyBytes_Check(pframe->f_code->co_name)", file=0x7f2c2892bd9c "apy_kemi.c", line=1819, function=0x7f2c2892d0b0 "sr_apy_kemi_exec_func") at assert.c:101 #4 0x00007f2c2890bd57 in sr_apy_kemi_exec_func () from /usr/lib/x86_64-linux-gnu/kamailio/modules/app_python3.so #5 0x00007f2c288d525c in ?? () from /usr/lib/x86_64-linux-gnu/kamailio/modules/app_python3.so #6 0x00007f2c282ad259 in PyCFunction_Call () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #7 0x00007f2c283de739 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #8 0x00007f2c283de6ad in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #9 0x00007f2c284a0074 in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #10 0x00007f2c283dcadf in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #11 0x00007f2c283de6ad in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #12 0x00007f2c284a0074 in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #13 0x00007f2c284a0153 in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #14 0x00007f2c28333558 in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #15 0x00007f2c2840fa37 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #16 0x00007f2c2845b95c in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #17 0x00007f2c2840fa37 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #18 0x00007f2c2849eb77 in PyEval_CallObjectWithKeywords () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 #19 0x00007f2c2891c136 in apy_exec () from /usr/lib/x86_64-linux-gnu/kamailio/modules/app_python3.so #20 0x00007f2c288dfe94 in sr_kemi_config_engine_python () from /usr/lib/x86_64-linux-gnu/kamailio/modules/app_python3.so #21 0x0000558ec29ba7b4 in sr_kemi_route () #22 0x0000558ec2ab7c03 in receive_msg () #23 0x0000558ec2997e4a in udp_rcv_loop () #24 0x0000558ec28de718 in main_loop () #25 0x0000558ec28e7a39 in main () ``` The fuller backtrace for the top few frames: ``` Thread 1 (Thread 0x7f2c3031db40 (LWP 26211)): #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 set = {__val = {0, 140720998929208, 139827752272384, 139827751795724, 140724530937856, 94071669029552, 94071669029653, 94071669029552, 94071669029552, 94071669029661, 94071669029852, 94071669029552, 94071669029852, 0, 0, 0}} pid = <optimized out> tid = <optimized out> #1 0x00007f2c2f76042a in __GI_abort () at abort.c:89 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x558ec469d990, sa_sigaction = 0x558ec469d990}, sa_mask = {__val = { 139827751803746, 140720998929248, 109, 139827755099200, 1819, 139827635998896, 139827635638836, 139827752272384, 139827751811289, 139827755115808, 139827751803256, 139827752815328, 139827752801040, 94071641717939, 139827763892224, 139827635994024}}, sa_flags = 1819, sa_restorer = 0x7f2c2892d0b0} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007f2c2f757e67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7f2c2892bda8 "PyBytes_Check(pframe->f_code->co_name)", file=file@entry=0x7f2c2892bd9c "apy_kemi.c", line=line@entry=1819, function=function@entry=0x7f2c2892d0b0 "sr_apy_kemi_exec_func") at assert.c:92 str = 0x558ec466a760 "" total = 4096 #3 0x00007f2c2f757f12 in __GI___assert_fail (assertion=0x7f2c2892bda8 "PyBytes_Check(pframe->f_code->co_name)", file=0x7f2c2892bd9c "apy_kemi.c", line=1819, function=0x7f2c2892d0b0 "sr_apy_kemi_exec_func") at assert.c:101 No locals. #4 0x00007f2c2890bd57 in sr_apy_kemi_exec_func () from /usr/lib/x86_64-linux-gnu/kamailio/modules/app_python3.so No symbol table info available. #5 0x00007f2c288d525c in ?? () from /usr/lib/x86_64-linux-gnu/kamailio/modules/app_python3.so No symbol table info available. #6 0x00007f2c282ad259 in PyCFunction_Call () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #7 0x00007f2c283de739 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #8 0x00007f2c283de6ad in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #9 0x00007f2c284a0074 in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #10 0x00007f2c283dcadf in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #11 0x00007f2c283de6ad in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #12 0x00007f2c284a0074 in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #13 0x00007f2c284a0153 in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #14 0x00007f2c28333558 in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #15 0x00007f2c2840fa37 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #16 0x00007f2c2845b95c in ?? () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #17 0x00007f2c2840fa37 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #18 0x00007f2c2849eb77 in PyEval_CallObjectWithKeywords () from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 No symbol table info available. #19 0x00007f2c2891c136 in apy_exec () from /usr/lib/x86_64-linux-gnu/kamailio/modules/app_python3.so No symbol table info available. #20 0x00007f2c288dfe94 in sr_kemi_config_engine_python () from /usr/lib/x86_64-linux-gnu/kamailio/modules/app_python3.so No symbol table info available. #21 0x0000558ec29ba7b4 in sr_kemi_route () No symbol table info available. #22 0x0000558ec2ab7c03 in receive_msg () No symbol table info available. #23 0x0000558ec2997e4a in udp_rcv_loop () No symbol table info available. #24 0x0000558ec28de718 in main_loop () No symbol table info available. #25 0x0000558ec28e7a39 in main () No symbol table info available. ``` For what it's worth, line 1819 in `apy_kemi.c` in the latest 5.3 `HEAD` (which I'm not sure this binary package reflects) is: ``` 1801 if(unlikely(cfg_get(core, core_cfg, latency_limit_action)>0) 1802 && is_printable(cfg_get(core, core_cfg, latency_log))) { 1803 gettimeofday(&tve, &tz); 1804 tdiff = (tve.tv_sec - tvb.tv_sec) * 1000000 1805 + (tve.tv_usec - tvb.tv_usec); 1806 if(tdiff >= cfg_get(core, core_cfg, latency_limit_action)) { 1807 pstate = PyThreadState_GET(); 1808 if (pstate != NULL && pstate->frame != NULL) { 1809 pframe = pstate->frame; 1810 } 1811 1812 LOG(cfg_get(core, core_cfg, latency_log), 1813 "alert - action KSR.%s%s%s(...)" 1814 " took too long [%u ms] (file:%s func:%s line:%d)\n", 1815 (ket->mname.len>0)?ket->mname.s:"", 1816 (ket->mname.len>0)?".":"", ket->fname.s, tdiff, 1817 (pframe)?PyBytes_AS_STRING(pframe->f_code->co_filename):"", 1818 (pframe)?PyBytes_AS_STRING(pframe->f_code->co_name):"", 1819 (pframe)?PyCode_Addr2Line(pframe->f_code, pframe->f_lasti):0); 1820 } 1821 } 1822 1823 return ret; 1824 } 1825 ``` That's inside `sr_apy_kemi_exec_func()`. Some suspicion falls upon this Python function: ``` def set_send_socket(self): KSR.info('[socket] forced_socket is: {}'.format(KSR.pv.get('$fs'))) if KSR.pv.get('$fs'): KSR.info('[socket] socket already set') return elif not self.is_local(): KSR.info('[socket] set socket to 5065') KSR.corex.set_send_socket(MY_IP + ':5065') else: KSR.info('[socket] set socket to 5060') KSR.corex.set_send_socket(MY_IP + ':5060') KSR.info('[socket] socket set') ``` ... simply because the last message out of KEMI which appears prior to the crash is one of its log emissions ... ``` May 21 18:20:25 proxy1 /usr/sbin/kamailio[26210]: INFO: 1697311439-5060-88(a)BA.CFC.EH.IF - {NOTIFY}: <core> [core/kemi.c:104]: sr_kemi_core_info(): domain exists result: None May 21 18:20:25 proxy1 /usr/sbin/kamailio[26211]: INFO: 1361696919-5060-39(a)BA.CFC.EH.BFC - {NOTIFY}: <core> [core/kemi.c:104]: sr_kemi_core_info(): [socket] forced_socket is: None May 21 18:20:25 proxy1 /usr/sbin/kamailio[26213]: INFO: 813204231-5060-53(a)BA.BF.J.CBF - {NOTIFY}: <core> [core/receive.c:518]: receive_msg(): reply-route executed in: 260 usec May 21 18:20:25 proxy1 /usr/sbin/kamailio[26212]: INFO: 1941306664-5060-17(a)BA.CFC.EH.CAG - {NOTIFY}: <core> [core/receive.c:518]: receive_msg(): reply-route executed in: 412 usec May 21 18:20:25 proxy1 /usr/sbin/kamailio[26209]: ALERT: <core> [main.c:766]: handle_sigs(): child process 26210 exited by a signal 6 May 21 18:20:25 proxy1 /usr/sbin/kamailio[26209]: ALERT: <core> [main.c:769]: handle_sigs(): core was not generated May 21 18:20:25 proxy1 /usr/sbin/kamailio[26209]: INFO: <core> [main.c:792]: handle_sigs(): terminating due to SIGCHLD ``` However, it's hard to troubleshoot without debug symbols and due to the third-party binary libraries, of course. Furthermore, the problem is not possible to reproduce on demand, though its incidence does seem to correlate to higher call volumes. Would building from source to provide more flexibility be recommended at this stage? -- 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/2335

4 4

← Newer
1
...
6
7
8
9
10
11
12
...
40
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev May 2020