sr-dev April 2025

sr-dev@lists.kamailio.org

14 participants
205 discussions

[kamailio/kamailio] rtpengine: select node with weight=0 if no other nodes online (Issue #4180)
by sergey-safarov 13 May '25

13 May '25

sergey-safarov created an issue (kamailio/kamailio#4180) ### Description I have installed two `rtpengine` instances and want to use them as an `active backup`. I want to use `backup` only when `active` is unavailable. Closest settings for this rtpengine node `weight` and want to use settings like ``` MariaDB [kamailio]> select * from rtpengine; +----+-------+---------------------------------+--------+----------+---------------------+ | id | setid | url | weight | disabled | stamp | +----+-------+---------------------------------+--------+----------+---------------------+ | 1 | 0 | udp6:[2005:84c0:bf:11::20]:2223 | 1 | 0 | 1900-01-01 00:00:01 | | 2 | 0 | udp6:[2005:84c0:bf:11::21]:2223 | 0 | 0 | 1900-01-01 00:00:01 | +----+-------+---------------------------------+--------+----------+---------------------+ ``` But in case `weight=0` node is not selected and handled as disabled. It will be fine do not use rtpengine nodes with `weight=0` when other rtpengine with `weight!=0` are available. But if no other nodes are available, use `weight=0` nodes as last resort. ### Expected behavior Do not use rtpengine nodes with `weight=0` when other rtpengine with `weight!=0` are available. But if no other nodes are available, use `weight=0` nodes as last resort. #### Actual observed behavior The node is not selected and handled as disabled when `weight=0`. #### Log Messages ``` rtpengine [rtpengine.c:3430]: rtpp_test(): rtpengine instance <udp6:[2005:84c0:bf:11::21]:2223> found, support for it enabled rtpengine [rtpengine.c:3883]: select_rtpp_node(): rtpengine failed to select new for calllen=27 callid=1-10824@2005:84c0:bf:11::22 rtpengine [rtpengine.c:3183]: rtpp_function_call(): no available proxies ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4180 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4180(a)github.com>

3 3

[kamailio/kamailio] WSS-connections show up as <null> in $tls_version and $tls_cypher_info (Issue #4167)
by Christian Berger 12 May '25

12 May '25

ChristianBergerSipgate created an issue (kamailio/kamailio#4167) Hi, we have found a potential bug. The pseudo variables return null for WSS connections. Example config: `xlog("L_INFO", "<mainLogic> REGISTER: TLS or WSS detected: fU=$fU tls_version=$tls_version tls_cipher_info=$tls_cipher_info ua=$ua\n");` Log output: `Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "ERROR", "module": "tls", "file": "tls_select.c", "line": 131, "function": "get_cur_connection", "message": "Transport protocol is not TLS (bug in config)\n" } Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "INFO", "module": "tls", "file": "tls_select.c", "line": 310, "function": "get_version", "message": "TLS connection not found in select_version\n" } Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "ERROR", "module": "tls", "file": "tls_select.c", "line": 131, "function": "get_cur_connection", "message": "Transport protocol is not TLS (bug in config)\n" } Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "INFO", "module": "tls", "file": "tls_select.c", "line": 201, "function": "get_cipher", "message": "TLS connection not found in select_cipher\n" } Mar 7 08:37:28 sip-tcploadbalancer01 /usr/sbin/kamailio[1268940]: { "level": "INFO", "module": "xlog", "file": "xlog.c", "line": 278, "function": "", "message": "<mainLogic> REGISTER: TLS or WSS detected: fU=1125411e0 tls_version=<null> tls_cipher_info=<null> ua=webphone\n" }` As you can see both tls_version and tls_cipher_info return <null> even though the underlying connection is via WSS. We have looked into it, and it seems like `get_cur_connection` in `modules/tls/tls_select.c` only checks for TLS, but not WSS. ``` struct tcp_connection *get_cur_connection(struct sip_msg *msg) { struct tcp_connection *c; if(_tls_pv_con != 0) return _tls_pv_con; if(msg->rcv.proto != PROTO_TLS) { ERR("Transport protocol is not TLS (bug in config)\n"); return 0; } c = tcpconn_get(msg->rcv.proto_reserved1, 0, 0, 0, cfg_get(tls, tls_cfg, con_lifetime)); if(c && c->type != PROTO_TLS) { ERR("Connection found but is not TLS\n"); tcpconn_put(c); return 0; } return c; } ``` We think that checking for `PROTO_WSS` might solve the issue. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4167 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4167(a)github.com>

4 5

[kamailio/kamailio] dispatcher: OPTIONS check does not triggered after new target added (Issue #4212)
by sergey-safarov 12 May '25

12 May '25

sergey-safarov created an issue (kamailio/kamailio#4212) ### Description When I add a new dispatcher target using the kamcmd command, then kamailio does not start send OPTIONS. #### Reproduction Need to start Kamailio with config file ``` listen=eth0 loadmodule "xlog.so" loadmodule "pv.so" loadmodule "ctl.so" loadmodule "jsonrpcs.so" loadmodule "dispatcher.so" modparam("dispatcher", "list_file", "/dev/null") route{ xerr("TEST $ci\n"); drop; } ``` And then execute comands ``` kamcmd dispatcher.add 1 "sip:sip.telnyx.com:5060;transport=tcp" 8 kamcmd dispatcher.list ``` After the last command expected output ``` { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:sip.telnyx.com:5060;transport=tcp FLAGS: AP PRIORITY: 0 } } } } } ``` As you can see, the target has `AP` flags, which means the target is active and probing enabled. But no OPTIONS messages were sent. #### Log Messages Here is kamailio debug output for during kamcmd execitions and some time after ``` 12(94363) DEBUG: ctl [../../core/io_wait.h:368]: io_watch_add(): processing io_watch_add(0x7fce67ac03a0, 10, 3, 0x21186bf0) - fd_no=1 12(94363) DEBUG: ctl [io_listener.c:440]: handle_new_connect(): new connection (1) on /var/run/kamailio//kamailio_ctl 12(94363) DEBUG: ctl [io_listener.c:501]: handle_stream_read(): bytes read: 68 12(94363) DEBUG: <core> [core/dns_cache.c:533]: _dns_hash_find(): (sip.telnyx.com(14), 1), h=507 12(94363) DEBUG: <core> [core/resolve.c:1021]: get_record(): skipping 0 NS (p=0x9c6ad0, end=0x9c6ad0) 12(94363) DEBUG: <core> [core/resolve.c:1035]: get_record(): parsing 0 ARs (p=0x9c6ad0, end=0x9c6ad0) 12(94363) DEBUG: <core> [core/dns_cache.c:1699]: dns_get_related(): (0x7fce63a32000 (sip.telnyx.com, 1), 1, *(nil)) (0) 12(94363) DEBUG: <core> [core/dns_cache.c:1702]: dns_get_related(): record not alone: 0x7fce63a32000 - type: 1 12(94363) DEBUG: <core> [core/dns_cache.c:748]: dns_cache_add_unsafe(): adding sip.telnyx.com(14) 1 (flags=0) at 507 12(94363) DEBUG: dispatcher [dispatch.c:768]: add_dest2list(): dest [1/1] <sip:sip.telnyx.com:5060;transport=tcp> 12(94363) DEBUG: dispatcher [dispatch.c:258]: ds_log_dst_cb(): dst>> 1 sip:sip.telnyx.com:5060;transport=tcp 8 0 (,0,0,0) 12(94363) DEBUG: ctl [io_listener.c:522]: handle_stream_read(): bytes processed: 68 12(94363) DEBUG: ctl [io_listener.c:498]: handle_stream_read(): handle_stream read: eof on /var/run/kamailio//kamailio_ctl 12(94363) DEBUG: ctl [../../core/io_wait.h:599]: io_watch_del(): DBG: io_watch_del (0x7fce67ac03a0, 10, -1, 0x10) fd_no=2 called 12(94363) DEBUG: ctl [../../core/io_wait.h:368]: io_watch_add(): processing io_watch_add(0x7fce67ac03a0, 10, 3, 0x21186bf0) - fd_no=1 12(94363) DEBUG: ctl [io_listener.c:440]: handle_new_connect(): new connection (1) on /var/run/kamailio//kamailio_ctl 12(94363) DEBUG: ctl [io_listener.c:501]: handle_stream_read(): bytes read: 25 12(94363) DEBUG: ctl [io_listener.c:522]: handle_stream_read(): bytes processed: 25 12(94363) DEBUG: ctl [io_listener.c:498]: handle_stream_read(): handle_stream read: eof on /var/run/kamailio//kamailio_ctl 12(94363) DEBUG: ctl [../../core/io_wait.h:599]: io_watch_del(): DBG: io_watch_del (0x7fce67ac03a0, 10, -1, 0x10) fd_no=2 called ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 6.0.1 (x86_64/linux) fce50d 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: fce50d compiled on 00:00:00 Sep 13 2022 with gcc 14.2.1 ``` * **Operating System**:  ``` root@nout:~# cat /etc/os-release NAME="Fedora Linux" VERSION="41 (Workstation Edition)" RELEASE_TYPE=stable ID=fedora VERSION_ID=41 VERSION_CODENAME="" PLATFORM_ID="platform:f41" PRETTY_NAME="Fedora Linux 41 (Workstation Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:41" DEFAULT_HOSTNAME="fedora" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f41/system-administrators-guide/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=41 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=41 SUPPORT_END=2025-12-15 VARIANT="Workstation Edition" VARIANT_ID=workstation ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4212 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4212(a)github.com>

3 8

[kamailio/kamailio] Improve and document cdp module list_peers output (Issue #4226)
by Henning Westerholt 12 May '25

12 May '25

henningw created an issue (kamailio/kamailio#4226) Improve and document cdp module list_peers output Example output: reg03:~$ sudo kamcmd cdp.list_peers { Realm: YYY.com Identity: 212.XX.XX.3 Accept unknown peers: 0 Connect timeout: 5 Transaction timeout: 5 Default auth session timeout: 3600 Queue length: 32 Workers: 8 Peer count: 3 Peers: { FQDN: 212.XX.XX.1 Details: { State: R_Open Disabled: False Last used: 1745907094 Applications: { appid:vendorid: 4:10415 } } FQDN: 212.XX.XX.2 Details: { State: R_Open Disabled: False Last used: -1406883582 Applications: { appid:vendorid: 4:10415 } } FQDN: 212.XX.XX.3 Details: { State: R_Open Disabled: False Last used: 1745907095 Applications: { appid:vendorid: 4:10415 } } } } 1. Add list_peers command to module XML docs 2. Document State meaning (e.g. what means R_Open etc..) 3. Check/ probably cast time_t value to not output negative numbers -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4226 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4226(a)github.com>

1 2

[kamailio/kamailio] cmake: switching deb rules (Issue #4053)
by Victor Seva 10 May '25

10 May '25

Opening this generic issue to track issues when trying to switch deb package generation to cmake: -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4053 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4053(a)github.com>

5 56

[kamailio/kamailio] cdp: restructure locking order to prevent rare deadlock (PR #4191)
by Morten Tryfoss 06 May '25

06 May '25

#### 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 - [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:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description We've been running the ims_charging module in production for quite some time, without any issues. A couple of days ago the whole instance freezed, but I was able to get a dump before the stuck processes before restarting. The traffic volume has gradually increased over time, so it's likely related to that. I then did a summary of the different types of stuck processes. Which locks they're holding, and what they're waiting for: ``` holding lock: AAASessionsLock waiting for lock: lock_get(peer_list_lock); #1 0x00007fe70eba8cde in futex_get (lock=0x7fe6e4a5c680) at ../../core/futexlock.h:108 #2 0x00007fe70ebaaca2 in get_peer_by_fqdn (fqdn=0x7fe6e4a5ba30) at peermanager.c:259 #3 0x00007fe70ebb64b7 in get_first_connected_route (cdp_session=0x7fe6e5cc5350, r=0x7fe6e4a5ba30, app_id=4, vendor_id=10415) at routing.c:115 #4 0x00007fe70ebb9a37 in get_routing_peer (cdp_session=0x7fe6e5cc5350, m=0x7fe6e5447ab0) at routing.c:293 #5 0x00007fe70ebcaf8c in AAASendMessage (message=0x7fe6e5447ab0, callback_f=0x7fe707a9e323 <resume_on_initial_ccr>, callback_param=0x7fe6e5297110) at diameter_comm.c:139 #6 0x00007fe707a9d3e0 in Ro_Send_CCR (msg=0x7fe70f011100, dlg=0x7fe6e5c571f0, dir=0, reservation_units=30, incoming_trunk_id=0x7ffe50efb060, outgoing_trunk_id=0x7ffe50efb050, pani=0x7ffe50efaee0, action=0x7fe70efa4730, tindex=10484, tlabel=677172593) at ims_ro.c:1511 #7 0x00007fe707a8285d in ki_ro_ccr (msg=0x7fe70f011100, s_route_name=0x7ffe50efb080, s_direction=0x7ffe50efb070, reservation_units=30, s_incoming_trunk_id=0x7ffe50efb060, s_outgoing_trunk_id=0x7ffe50efb050) at ims_charging_mod.c:742 #8 0x00007fe707a7bf01 in w_ro_ccr (msg=0x7fe70f011100, c_route_name=0x7fe70ef8b8d0 "\220\311\371\016\347\177", c_direction=0x7fe70ef8b980 "p\240\371\016\347\177", reservation_units=30, c_incoming_trunk_id=0x7fe70ef8ba30 "p\241\371\016\347\177", c_outgoing_trunk_id=0x7fe70ef8bae0 "\360\241\371\016\347\177") at ims_charging_mod.c:507 #9 0x00000000004858d8 in do_action (h=0x7ffe50efb970, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1144 #10 0x00000000004928d6 in run_actions (h=0x7ffe50efb970, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1618 #11 0x0000000000492f52 in run_actions_safe (h=0x7ffe50eff1e0, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1681 #12 0x0000000000450156 in rval_get_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, i=0x7ffe50efbec8, rv=0x7fe70ef9c1d8, cache=0x0) at core/rvalue.c:973 #13 0x0000000000454d24 in rval_expr_eval_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, res=0x7ffe50efbec8, rve=0x7fe70ef9c1d0) at core/rvalue.c:1854 #14 0x0000000000454d52 in rval_expr_eval_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, res=0x7ffe50efc448, rve=0x7fe70ef9b920) at core/rvalue.c:1864 #15 0x00000000004850ce in do_action (h=0x7ffe50eff1e0, a=0x7fe70ef9b070, msg=0x7fe70f011100) at core/action.c:1097 -- holding lock: AAASessionsLock waiting for lock: lock_get(peer_list_lock); #1 0x00007fe70eba8d4f in futex_get (lock=0x7fe6e4a5c680) at ../../core/futexlock.h:121 #2 0x00007fe70ebaaca2 in get_peer_by_fqdn (fqdn=0x7ffe50efab90) at peermanager.c:259 #3 0x00007fe70ebb8e89 in get_routing_peer (cdp_session=0x7fe6e5ab6910, m=0x7fe6e5435be0) at routing.c:252 #4 0x00007fe70ebcaf8c in AAASendMessage (message=0x7fe6e5435be0, callback_f=0x7fe707a95edc <resume_on_termination_ccr>, callback_param=0x0) at diameter_comm.c:139 #5 0x00007fe707a95b02 in send_ccr_stop_with_param (ro_session=0x7fe6e5ab65e0, code=0, reason=0x7ffe50efb060) at ims_ro.c:1181 #6 0x00007fe707a72ff7 in dlg_terminated (dlg=0x7fe6e623d7a0, type=64, termcode=0, reason=0x7fe707ab72b3 "normal call clearing", _params=0x7fe707f67280 <params>) at dialog.c:249 #7 0x00007fe707a6a729 in dlg_callback_received (dlg=0x7fe6e623d7a0, type=64, _params=0x7fe707f67280 <params>) at dialog.c:25 #8 0x00007fe707d341b9 in run_dlg_callbacks (type=64, dlg=0x7fe6e623d7a0, req=0x7fe70f011100, rpl=0x0, dir=1, dlg_data=0x0) at dlg_cb.c:271 #9 0x00007fe707cf4db4 in dlg_terminated (req=0x7fe70f011100, dlg=0x7fe6e623d7a0, dir=1) at dlg_handlers.c:413 #10 0x00007fe707cfddeb in dlg_onroute (req=0x7fe70f011100, route_params=0x7ffe50efb6d0, param=0x0) at dlg_handlers.c:1097 #11 0x00007fe70ad285f6 in run_rr_callbacks (req=0x7fe70f011100, rr_param=0x7ffe50efb7c0) at rr_cb.c:96 #12 0x00007fe70ad3ae92 in after_loose (_m=0x7fe70f011100, preloaded=0) at loose.c:1021 #13 0x00007fe70ad3b5ce in loose_route_mode (_m=0x7fe70f011100, _mode=0) at loose.c:1056 #14 0x00007fe70ad3f74f in w_loose_route (msg=0x7fe70f011100, p1=0x0, p2=0x0) at rr_mod.c:273 #15 0x00000000004855ff in do_action (h=0x7ffe50efc390, a=0x7fe70efe0d40, msg=0x7fe70f011100) at core/action.c:1121 -- holding lock: lock_get(peer_list_lock); waiting for lock: lock_get(p->lock); #1 0x00007fe70eba8d4f in futex_get (lock=0x7fe6e4a5cbd0) at ../../core/futexlock.h:121 #2 0x00007fe70ebab0ae in peer_timer (now=1742807320, ptr=0x0) at peermanager.c:286 #3 0x00007fe70ebd0f39 in timer_loop () at timer.c:116 #4 0x00007fe70ebd21b2 in timer_process (returns=0) at timer.c:216 #5 0x00007fe70eb8ccf8 in diameter_peer_start (blocking=0) at diameter_peer.c:350 #6 0x00007fe70eb7cbb2 in cdp_child_init (rank=0) at cdp_mod.c:272 -- holding lock: lock_get(p->lock) waiting for lock: AAASessionsLock #1 0x00007fe70ebf2597 in futex_get (lock=0x7fe6e4a5d490) at ../../core/futexlock.h:108 #2 0x00007fe70ebf26f1 in AAASessionsLock (hash=0) at session.c:79 #3 0x00007fe70ebf5e6e in cdp_get_session (id=...) at session.c:316 #4 0x00007fe70eba6892 in Snd_Message (p=0x7fe6e4a5c880, msg=0x7fe6e63998d0) at peerstatemachine.c:1237 #5 0x00007fe70eba003e in sm_process (p=0x7fe6e4a5c880, event=Send_Message, msg=0x7fe6e63998d0, peer_locked=0, sock=0) at peerstatemachine.c:429 #6 0x00007fe70ebcbdc6 in AAASendMessage (message=0x7fe6e63998d0, callback_f=0x7fe707a8f208 <resume_on_interim_ccr>, callback_param=0x7fe6e6190a90) at diameter_comm.c:166 #7 0x00007fe707a8edb3 in send_ccr_interim (ro_session=0x7fe6e5399160, used=60, reserve=30) at ims_ro.c:847 #8 0x00007fe707a68bd6 in ro_session_ontimeout (tl=0x7fe6e5399200) at ro_timer.c:513 #9 0x00007fe707a63078 in ro_timer_routine (ticks=114862426, attr=0x0) at ro_timer.c:279 #10 0x00000000004fd33e in compat_old_handler (ti=1837798827, tl=0x7fe6e4cf6260, data=0x7fe6e4cf6260) at core/timer.c:980 #11 0x00000000004fde7a in slow_timer_main () at core/timer.c:1103 #12 0x000000000042e4e7 in main_loop () at main.c:1911 #13 0x000000000043876c in main (argc=10, argv=0x7ffe50f001c8) at main.c:3236 ``` In `get_first_connected_route()` in `routing.c` of the cdp module there are two places `get_peer_by_fqdn()` are called. One of them has an unlock/relock of the session list before and after (and a comment about holding two locks at a time), while the other doesn't. I'm currently testing two version of this. The first by just doing the some relock for the other `get_peer_by_fqdn()`, but this PR got an approach for maybe fixing more latent issues. `sm_process()` also got some strange handling by `Rcv_Process()` after the peer lock is released, which seems to be about the same thing. My deadlock is for the `Snd_Message()` equivalent. I've now removed this queueing behaviour, and instead doing a re-lock of the peer to (hopefully) have the same locking order as the other operations. The problem with this thing is how rare it occurs. Just wanted to share my findings for others with more knowledge to the cdp module for comments, suggestions and hopefully some extra testing. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4191 -- Commit Summary -- * cdp: restructure locking order to prevent rare deadlock -- File Changes -- M src/modules/cdp/peerstatemachine.c (25) M src/modules/cdp/routing.c (6) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4191.patch https://github.com/kamailio/kamailio/pull/4191.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4191 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4191(a)github.com>

4 13

[kamailio/kamailio] stirshaken: removed repeated x509 certification path check (PR #4202)
by Felipe Cuadra Plaza 06 May '25

06 May '25

2 2

[kamailio/kamailio] app_jstd: Added dynamic buffer sizing to load bigger .js files and Added ability to load all JavaScript files from a specified directory (PR #4221)
by nickgashcc 06 May '25

06 May '25

2 9

[kamailio/kamailio] Feature/tcp/tls domain matching (PR #4222)
by Michael Furmur 06 May '25

06 May '25

2 4

[kamailio/kamailio] cdp: Cast time for printing and Improve cdp docs (PR #4227)
by Xenofon Karamanos 06 May '25

06 May '25

2 2

← Newer
1
2
3
4
5
6
7
...
21
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev April 2025