sr-dev February 2023

sr-dev@lists.kamailio.org

10 participants
294 discussions

[kamailio/kamailio] ims_registrar_pcscf: changes for ul db_mode DB_ONLY (PR #3317)

by petermarianF

Enable registration of pcscf contact callback during download from db location table and inserting pcontact (normally this callback is registered during handling of REGISTER). Refuse REGISTER when pcontact is expired since [0 to 20] seconds. Within this time window a NOTIFY is expected from scscf and in order to avoid race time conditions between scscf and pcscf REGISTER will be refused. Refuse REGISTER when pcontact is expired longer than 20 seconds - send PUBLISH (contact expired) to scscf to trigger NOTIFY. In both REGISTER refused scenarios routing script should reply 500 - Deregister in progress.   #### 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  In case a pcontact found in location db has to be inserted into pcscf cache depending on contact state also callbacks have to be registered for this pcontact. Registering of callback_pcscf_contact_cb is enabled in this module. Handling of contact expiry is usually triggered in the scscf (mem_timer_udomain which runs every 10 secs). Sending of NOTIFY to pcscf may take up to 20 seconds from start of expiry due to timing conditions. To avoid race time conditions between a REREGISTER and the expiry handler state machine in the scscf an approach is chosen to refuse a REREGISTER in time window of 20 seconds after pcontact expiry on the pcscf (thus allowing expiry handling to finish). REREGISTER is refused in this scenario with new return_code -2. In case a REREGISTER arrives at pcscf and the respective pcontact is expired longer than time window of 20 seconds registration also is refused with rc -2 and additionaly PUBLISH is sent to scscf with expiry = 0. The rc -2 shall be handled in register.cfg script as follows: pcscf_save_pending("location"); switch ($retcode) { case -1: # Missing/wrong Information in REGISTER. send_reply("400", "Information wrong - See log."); exit; break; case -2: # De-Register in Progress, or PUBLISH ongoing due to registration expiry, # or new REGISTER blocked because registration just expired (up to 20sec). append_to_reply("Retry-After: 30\r\n"); send_reply("500", "Deregister in progress - Please try again"); exit; break; } You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3317 -- Commit Summary -- * ims_registrar_pcscf: changes for ul db_mode DB_ONLY -- File Changes -- M src/modules/ims_registrar_pcscf/ims_registrar_pcscf_mod.c (21) M src/modules/ims_registrar_pcscf/notify.c (4) M src/modules/ims_registrar_pcscf/save.c (37) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3317.patch https://github.com/kamailio/kamailio/pull/3317.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3317 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3317(a)github.com>

1 year, 3 months

Dialog-Module and CSeq tracking

by Carsten Bock

Hi, Quick question: Looking at the Dialog module and CSeq tracking functionality, I've noticed the following: - on the one hand, we are storing the current CSeq for each direction in the Dialog structure - on the other hand, we are storing a "Delta" of the received vs. updated CSeq as a Dialog Variable Does replacing the Delta with the CSeq already stored with the Dialog structure make sense? I am asking because of my latest changes, where there may be more sources for an updated CSeq (e.g., when sending a Request from script within the Dialog) and more use cases for an updated CSeq (Up and Downstream). I've updated the dialog module for my use already accordingly https://github.com/kamailio/kamailio/compare/master...carstenbock/dialog_cs… I wanted to hear other opinions and possible pitfalls as well... Thanks, Carsten -- Carsten Bock I CTO & Founder ng-voice GmbH Trostbrücke 1 I 20457 Hamburg I Germany T +49 179 2021244 I www.ng-voice.com Registry Office at Local Court Hamburg, HRB 120189 Managing Directors: Dr. David Bachmann, Carsten Bock

1 year, 4 months

[kamailio/kamailio] Statistic counters for LCR module (Issue #3372)

by Alessio Garzi

### Description I am in need to get some statistic counters related to each lcr gw currently loaded in Kamailio. Kamailio already provides the counters I need inside the KEX module with the following command: ``` kamcmd> stats.get_statistics core: core:bad_URIs_rcvd = 69 core:bad_msg_hdr = 2 core:drop_replies = 0 core:drop_requests = 8499 core:err_replies = 0 core:err_requests = 0 core:fwd_replies = 4 core:fwd_requests = 65 core:rcv_replies = 502088 ... ``` Here kamailio doing exactly what i want, it's exposing the counter data via xmlrpc which is great for attaching an external tool to build statistics. Unfortunately Kamailio KEX module is counting every single request/reply hitting the proxy server, the idea is to have the above stats related to the gateways currently loaded by the lcr module. In this way, for example I can tell how many request/replies I got from gw id X or gw id Y and produce gw based stats. Unfortunately the KEX module has no "concept" of "GW" and "LCR", so the idea is to implement the same counting logic inside LCR module. The counting should not be persistent (counters must go to zero every time kamailio restarts). When adding or deleting a new gateway, the counting in memory must reflect the status of the internal state or lcr gatewas, so, for example, after adding a new gateway and reloading lcr tables, the new counters must be immediately available through xmlrpc without a new kamailio restart. The same concept applies when the gateway is removed from the list. ### Expected behavior A possible implementation should give the user to query counters in a way similar to this: ``` # kamcmd lcr.stats { gw: { { gw_id: <id of lcr mysql table here> gw_name: <description of lcr mysql table here> requests: 0 requests_invite: 0 requests_cancel: 0 ... } { gw_id: <id of lcr mysql table here> gw_name: <description of lcr mysql table here> requests: 0 requests_invite: 0 requests_cancel: 0 ... } } } ``` Additionally, it would be helpful to set a gw id as argument in order to filter, for example: ``` # kamcmd lcr.stats 95 { gw: { { gw_id: 95 gw_name: <description of gw id 95> requests: 222 requests_invite: 1 requests_cancel: 1 requests_ack: 1 ... } } } ``` #### Actual observed behavior To my knowledge, nothing related to this issue has been implemented in Kamailio so far -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3372 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3372(a)github.com>

1 year, 4 months

[kamailio/kamailio] kamailio 5.2.3(commit c36229) crash at free_cell_helper (Issue #3379)

by polite

### Description kamailio 5.2.3 crash at free_cell_helper ### Troubleshooting #### Reproduction This cannot be reproduced at will. #### Debugging Data ``` [root@VM-110-141-centos /data/coredump]# gdb -c core_kamailio_1676550458 /usr/local/services/kamailio/sbin/kamailio GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.tl2 Copyright (C) 2013 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-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/services/kamailio/sbin/kamailio...done. [New LWP 4452] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Missing separate debuginfo for /usr/local/services/kamailio/lib64/kamailio/libjansson.so.4 Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/fc/cf02c89115bf860ddba32e8b703205ffeeabf1.debug Core was generated by `/usr/local/services/kamailio/sbin/kamailio -f /usr/local/services/kamailio/etc/'. Program terminated with signal 11, Segmentation fault. #0 0x00007f8ede8e113a in free_cell_helper (dead_cell=0x7f8eb7dcb1b8, silent=0, fname=0x7f8ede9ece02 "timer.c", fline=689) at h_table.c:182 182 h_table.c: No such file or directory. Missing separate debuginfos, use: debuginfo-install bash-4.2.46-34.tl2.3.x86_64 cyrus-sasl-lib-2.1.26-23.el7.x86_64 glibc-2.17-323.tl2.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-51.tl2.x86_64 libcom_err-1.42.9-19.tl2.x86_64 libcurl-7.29.0-59.tl2.1.x86_64 libevent-2.0.21-4.el7.x86_64 libgcc-4.8.5-44.tl2.1.x86_64 libidn-1.28-4.el7.x86_64 libselinux-2.5-15.tl2.x86_64 libssh2-1.8.0-4.tl2.x86_64 libstdc++-4.8.5-44.tl2.1.x86_64 mariadb-libs-5.5.68-1.tl2.x86_64 nspr-4.32.0-1.tl2.x86_64 nss-3.67.0-4.tl2.x86_64 nss-softokn-freebl-3.67.0-3.tl2.x86_64 nss-util-3.67.0-1.tl2.x86_64 openldap-2.4.44-24.tl2.x86_64 openssl-libs-1.0.2k-22.tl2.1.x86_64 pcre-8.32-17.el7.x86_64 python-libs-2.7.5-90.tl2.1.x86_64 zlib-1.2.7-19.tl2.x86_64 (gdb) bt full #0 0x00007f8ede8e113a in free_cell_helper (dead_cell=0x7f8eb7dcb1b8, silent=0, fname=0x7f8ede9ece02 "timer.c", fline=689) at h_table.c:182 b = 0x7f8ede8decc4 <futex_release+29> "\211E\374\203}\374\002\017\224\300\017\266\300H\205\300t3H\213E\350\307\004$" i = 1 rpl = 0x7fffb5166580 tt = 0x7fffb51665a0 foo = 0x100000000 cbs = 0x7f8e00000001 cbs_tmp = 0x7f8e00000001 __FUNCTION__ = "free_cell_helper" #1 0x00007f8ede99381e in wait_handler (ti=367281959, wait_tl=0x7f8eb7dcb240, data=0x7f8eb7dcb1b8) at timer.c:689 p_cell = 0x7f8eb7dcb1b8 ret = 3080640456 unlinked = 0 rcount = 1 __FUNCTION__ = "wait_handler" #2 0x0000000000487769 in timer_list_expire (t=367281959, h=0x7f8eb7a318a8, slow_l=0x7f8eb7a34d70, slow_mark=42793) at core/timer.c:874 tl = 0x7f8eb7dcb240 ret = 0 #3 0x0000000000487bca in timer_handler () at core/timer.c:939 saved_ticks = 367281959 run_slow_timer = 0 i = 809 __FUNCTION__ = "timer_handler" #4 0x0000000000488074 in timer_main () at core/timer.c:978 No locals. #5 0x0000000000425a31 in main_loop () at main.c:1727 i = 8 pid = 0 si = 0x0 si_desc = "udp receiver child=7 sock=11.177.110.141:35560\000(175.27.32.249:15060)\000\177\000\000\223U{\000\000\000\000\000-\000\000\000\000\000\000\000\000\000\000 \000\000\000\000\000\000\000\004\000\000\000\000\257*\245\346\216\177\000\000\360\260y\000\000\000\000\000\000\227\265\342\216\177\000" nrprocs = 8 woneinit = 1 __FUNCTION__ = "main_loop" #6 0x000000000042c72d in main (argc=13, argv=0x7fffb5166bd8) at main.c:2696 cfg_stream = 0xfdc010 c = -1 r = 0 tmp = 0x7fffb5168757 "" tmp_len = 0 port = 0 proto = 2496 options = 0x76a700 ":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 = 99772630 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x7fffb5166a90 p = 0x7f8ee6a00d2d <intel_check_word+173> "H\205\300t\025\017\266P\003\017\266\312D9\371\017\204\316" st = {st_dev = 21, st_ino = 32759713, st_nlink = 2, st_mode = 16877, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1671615993, tv_nsec = 68240759}, st_mtim = {tv_sec = 1671620803, tv_nsec = 306084978}, st_ctim = {tv_sec = 1671620803, tv_nsec = 306084978}, __unused = {0, 0, 0}} __FUNCTION__ = "main" (gdb) info locals cfg_stream = 0xfdc010 c = -1 r = 0 tmp = 0x7fffb5168757 "" tmp_len = 0 port = 0 proto = 2496 options = 0x76a700 ":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 = 99772630 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x7fffb5166a90 p = 0x7f8ee6a00d2d <intel_check_word+173> "H\205\300t\025\017\266P\003\017\266\312D9\371\017\204\316" st = {st_dev = 21, st_ino = 32759713, st_nlink = 2, st_mode = 16877, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1671615993, tv_nsec = 68240759}, st_mtim = {tv_sec = 1671620803, tv_nsec = 306084978}, st_ctim = {tv_sec = 1671620803, tv_nsec = 306084978}, __unused = {0, 0, 0}} __FUNCTION__ = "main" (gdb) list 177 in h_table.c (gdb) ``` #### Log Messages kamailio.log ``` Feb 16 20:27:33 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4434]: INFO: {10 OPTIONS 3c7f4fb43ea4086d-4451(a)11.177.110.141} <script>: keepalive-host is up: OPTIONS sip:9.137.223.152:50180 (<null>) Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4425]: ALERT: <core> [main.c:756]: handle_sigs(): child process 4452 exited by a signal 11 Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4425]: ALERT: <core> [main.c:759]: handle_sigs(): core was generated Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4425]: INFO: <core> [main.c:781]: handle_sigs(): terminating due to SIGCHLD Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4470]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4469]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4462]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4466]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4467]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4468]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4464]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4449]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4460]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4465]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4461]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4440]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4459]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4429]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4457]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4430]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4456]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4442]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4432]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4458]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4437]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4444]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4463]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4439]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4454]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4434]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4448]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4451]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4436]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4447]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4450]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4435]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4431]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4441]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4446]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4428]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4445]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4427]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4453]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4438]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4455]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4433]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4443]: INFO: <core> [main.c:836]: sig_usr(): signal 15 received Feb 16 20:27:41 VM-110-141-centos /usr/local/services/kamailio/sbin/kamailio[4425]: CRITICAL: <core> [core/mem/q_malloc.c:137]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f8eb7d04778 (address 0x7f8eb7d047b0) end overwritten (1, abcdefed)! Memory allocator was called from dialplan: dp_db.c:687. Fragment marked by dialplan: dp_db.c:400. Exec from core/mem/q_malloc.c:504. ``` messages ``` [Thu Feb 16 20:27:44 2023] kamailio[4452]: segfault at 7f8e00000021 ip 00007f8ede8e113a sp 00007fffb51664a0 error 4 in tm.so[7f8ede8c5000+13a000] ``` #### SIP Traffic ### Possible Solutions ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` [root@VM-110-141-centos /usr/local/services/kamailio/sbin]# ./kamailio -version version: kamailio 5.2.3 (x86_64/linux) c36229 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: c36229 compiled on 16:50:57 Jul 16 2019 with gcc 4.8.5 ``` * **Operating System**: ``` [root@VM-110-141-centos /data/coredump]# uname -a Linux VM-110-141-centos 4.14.105-1-tlinux3-0023 #1 SMP Mon Jan 10 18:17:33 CST 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/3379 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3379(a)github.com>

1 year, 4 months

Releasing Kamailio v5.5.6

by Daniel-Constantin Mierla

Hello, I am considering to release Kamailio v5.5.6 soon, branch on branch 5.5, likely on Thursday or Wednesday next week (Mar 2/3, 2023). This is the usual heads up notification to see if anyone is aware of issues not yet reported to bug tracker and if yes, do it as soon as possible to give them a chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

1 year, 4 months

Re: [kamailio/kamailio] rtpengine: doc add codec-accept with an example (e8c294f)

by Ihor Olkhovskyi

Small typo here `codec-accept=opus` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/commit/e8c294f33f8b867b0f67d78c14b7327… You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/commit/e8c294f33f8b867b0f67d78c14b7327dc22dd726/102410069(a)github.com>

1 year, 4 months

[kamailio/kamailio] rtpengine: document options SDES-pad and SDES-nonew (PR #3369)

by Дилян Палаузов

You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3369 -- Commit Summary -- * rtpengine: document options SDES-pad and SDES-nonew -- File Changes -- M src/modules/rtpengine/bencode.h (2) M src/modules/rtpengine/doc/rtpengine_admin.xml (36) M src/modules/rtpengine/rtpengine.c (4) M src/modules/rtpengine/rtpengine_funcs.c (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3369.patch https://github.com/kamailio/kamailio/pull/3369.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3369 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3369(a)github.com>

1 year, 4 months

[kamailio/kamailio] RPC command sl.stats does not work correctly with large values (exceeding 4 bytes) (Issue #3386)

by Nicolas C

### Description Using kamcmd to obtain statistics of SIP replies, for large values (exceeding 4 bytes) : Example : ``` kamcmd> sl.stats { (...) 302: -1294967293 } ``` The variable is an unsigned long, it can store values up to 2^64-1. But RPC command **sl.stats** does not support this. ### Possible Solutions I think the fix is simple, we should just replace "d" by "j" when using "rpc->struct_add" (function "rpc_stats" in file src/modules/sl/sl_stats.c). E.g. : ``` rpc->struct_add(st, "jjjj", "300", total.err[RT_300], "301", total.err[RT_301], "302", total.err[RT_302], "3xx", total.err[RT_3xx]); ``` I found a commit that did something similar with the shared memory stats : https://github.com/kamailio/kamailio/commit/f619cae55ffeb4596da852d9ed75773… ### Additional Information Kamailio 5.6.4 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3386 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3386(a)github.com>

1 year, 4 months

[kamailio/kamailio] TLS module rpc commands not found (Issue #3385)

by HimaBinduGrg

We have loaded the tls.so module in the kamailio.cfg file and the kamailio process is up and running, however we are not sure whether the TLS module is loaded properly or not. Here are a few configuration details. #!ifdef WITH_TLS loadmodule "tls.so" #!endif #!ifdef WITH_TLS enable_tls=yes #!endif #!ifdef WITH_TLS ## ----- tls params ----- modparam("tls", "config", "/etc/kamailio/tls.cfg") #!endif $kamailio -v version: kamailio 5.5.3 (x86_64/linux) d31ff9-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: d31ff9 -dirty compiled on 10:08:08 May 24 2022 with gcc 8.5.0 # openssl version OpenSSL 1.1.1k FIPS 25 Mar 2021 # ldd /usr/lib64/kamailio/modules/tls.so linux-vdso.so.1 (0x00007ffc0cbf2000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f2c3bcc1000) libm.so.6 => /lib64/libm.so.6 (0x00007f2c3b93f000) libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f2c3b6ab000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f2c3b1c2000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2c3afa2000) libc.so.6 => /lib64/libc.so.6 (0x00007f2c3abdd000) /lib64/ld-linux-x86-64.so.2 (0x00007f2c3c170000) libz.so.1 => /lib64/libz.so.1 (0x00007f2c3a9c5000) When we try to check tls rpc cli's it shows command not found # kamcmd [tls.info](http://tls.info/) error: 500 - command [tls.info](http://tls.info/) not found # kamcmd tls.reload error: 500 - command tls.reload not found We have compiled the kamailio-5.5.3 version using the kamailio.spec file. kamailio-tls-5.5.3-5.el8.x86_64 rpm installed to load the tls.so module. Operating System : Red Hat Enterprise Linux release 8.6 (Ootpa) Please suggest to me anything we have missed to configure or compilation wise. Also suggest to me how to verify the tls module and configuration is fine or not. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3385 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3385(a)github.com>

1 year, 4 months

git:master:05b4fdeb: modules: readme files regenerated - htable ... [skip ci]

by Kamailio Dev

Module: kamailio Branch: master Commit: 05b4fdebcf2eb9c82739a643ff48b799b8046bbd URL: https://github.com/kamailio/kamailio/commit/05b4fdebcf2eb9c82739a643ff48b79… Author: Kamailio Dev <kamailio.dev(a)kamailio.org> Committer: Kamailio Dev <kamailio.dev(a)kamailio.org> Date: 2023-02-28T11:01:24+01:00 modules: readme files regenerated - htable ... [skip ci] --- Modified: src/modules/htable/README --- Diff: https://github.com/kamailio/kamailio/commit/05b4fdebcf2eb9c82739a643ff48b79… Patch: https://github.com/kamailio/kamailio/commit/05b4fdebcf2eb9c82739a643ff48b79…

1 year, 4 months

← Newer
1
...
9
10
11
12
13
14
15
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev February 2023