sr-dev August 2023

sr-dev@lists.kamailio.org

15 participants
207 discussions

[kamailio/kamailio] track_cseq_updates does not update Rack SIP header in PRACK. (#801)

by scfcplummy

Hi, When using dialog module and track_cseq_updates when needing to update CSeq for authenticated invites, if early media is present the CSeq in the Rack header is not also incremented. Kamailio version: version: kamailio 4.4.2 (x86_64/linux) 892ad6 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: 892ad6 compiled on 11:18:36 Sep 28 2016 with gcc 5.4.0 -- 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/801

1 year

[kamailio/kamailio] sca: implement db_mode only (#781)

by Victor Seva

Sipwise hat ON: We have more than one server and we need to keep things in db in order to share sca subscription/appearance between servers -- 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/781

1 year

[kamailio/kamailio] 5.6.4 debian htable dbmode=1 not writing at shutdown (Issue #3536)

by ednt

### Description I use debian 11 and Kamailio 5.6.x modparam("htable", "htable", "callpush=>size=10;autoexpire=86400;dbtable=callpush;dbmode=1") I can store the values in the table, but if I shutdown kamailio, the current values are not stored in the table. #### Reproduction Use a htable and dbtable and dbmode=1 and shutdown kamailio. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3536 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3536(a)github.com>

1 year

[kamailio/kamailio] Add Username support for authentication in redis and sentinel w.r.t NDB REDIS (Issue #3552)

by hemanth-vulavala

### Description The current issue revolves around the absence of username support within the NDB REDIS KAMALIO framework when dealing with Redis, particularly concerning the Redis and Sentinel components. While Redis inherently offers the capability to utilize both usernames and passwords during authentication, this capability is not currently extended to the NDB REDIS KAMALIO setup. As a result, when attempting to establish connections to Redis instances through NDB REDIS KAMALIO, there is no provision for providing a username as part of the authentication process. Instead, the framework only accommodates the usage of passwords for authentication. This stands in contrast to Redis, which permits the inclusion of both usernames and passwords for enhanced security measures. Consequently, the limitation within NDB REDIS KAMALIO can hinder organizations seeking to ensure comprehensive security practices, especially when the requirement is to employ both usernames and passwords for authentication. This divergence between the authentication capabilities of Redis and NDB REDIS KAMALIO can potentially compromise security standards and hinder compatibility with certain authentication setups. To address this issue, it would be essential for the development team behind NDB REDIS KAMALIO to enhance the framework's capabilities by incorporating support for username-based authentication in addition to passwords. This alignment with Redis's authentication model would ensure that organizations can confidently implement secure data interactions while maintaining consistency with established security policies  ### Expected behavior The expected behavior entails an improvement within the NDB REDIS KAMALIO framework to support both usernames and passwords for authentication when interacting with Redis instances, particularly in the Redis and Sentinel components. This enhancement would bring NDB REDIS KAMALIO in line with Redis's native authentication capabilities, where both usernames and passwords are accepted during the authentication process. Upon implementing this improvement, users of NDB REDIS KAMALIO should be able to configure their connections by providing both a username and a password as part of the authentication details. This allows NDB REDIS KAMALIO to establish connections to Redis instances that require both authentication credentials, thereby enhancing security and ensuring compatibility with various authentication setups. By incorporating support for usernames in addition to passwords, NDB REDIS KAMALIO can accommodate organizations that require comprehensive security measures, especially in scenarios where username-based authentication is mandated. This alignment with Redis's authentication model would enable organizations to effectively collect, manage, and interact with data while adhering to established security policies. In summary, the expected behavior is that NDB REDIS KAMALIO should be upgraded to offer support for usernames and passwords during authentication, mirroring Redis's capabilities. This enhancement ensures a consistent and secure approach to data interactions and supports various authentication requirements within Redis environments #### Actual observed behavior The current actual behavior is that NDB REDIS KAMALIO does not have the capability to accept usernames as part of the authentication process when connecting to Redis instances, specifically in both the Redis and Sentinel components. While Redis itself allows for the usage of both usernames and passwords for authentication, this feature is not currently integrated into the NDB REDIS KAMALIO framework. As a result, when configuring connections to Redis instances using NDB REDIS KAMALIO, there is no provision to include a username alongside the authentication details. The framework only accommodates the use of passwords for authentication purposes. This deviation from Redis's authentication model could lead to compatibility issues with certain authentication setups, particularly those that mandate the use of both usernames and passwords. In essence, the actual behavior is that NDB REDIS KAMALIO falls short of aligning with Redis's authentication capabilities, thereby potentially hindering secure data interactions and limiting compatibility with certain security policies. Users attempting to adhere to comprehensive authentication practices may face challenges when utilizing NDB REDIS KAMALIO due to its inability to support usernames during authentication. To address this actual behavior, it would be necessary to enhance NDB REDIS KAMALIO's capabilities to include support for both usernames and passwords during the authentication process. This enhancement would ensure that organizations can confidently utilize NDB REDIS KAMALIO while maintaining the security standards and authentication requirements necessary for their Redis environments. #### 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) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3552 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3552(a)github.com>

1 year

[kamailio/kamailio] Support for Password Authentication in Sentinel for NDB Redis in kamailio (Issue #3530)

by hemanth-vulavala

### Description Currently, kamailio NDB Redis integration with Sentinel does not offer support for password authentication, leading to potential security concerns in our system. As a result, we are unable to ensure the desired level of protection for sensitive data stored in Redis. *Expected Behavior:* We expect Kamailio to allow the configuration of password authentication for Sentinel in the NDB Redis integration, enabling a secure and password-protected connection to the Redis instances. *Proposed Solution:* To address this issue, we recommend implementing a feature that enables password authentication for the Sentinel-based NDB Redis connections. This improvement will provide an added layer of security, ensuring that only authorized users can access the Redis instances. *Impact:* The absence of password authentication support poses a security risk, making our system vulnerable to potential unauthorized access and data breaches. Implementing this enhancement will safeguard sensitive information and strengthen our Redis integration's security framework. Note: as of now NDB REDIS support redis authentication using password  ### Troubleshooting #### Reproduction Steps to Reproduce:* 1. Attempt to configure password authentication for Sentinel in kamailio NDB Redis integration. ex: modparam("ndb_redis", "server", "name=srvZ;sentinel_group=group_name;sentinel_master=1;sentinel=1.2.3.4:26379;sentinel=1.2.3.5:26379";pass=mypassword") *It is failed to connect the sentinel *  #### 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) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3530 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3530(a)github.com>

1 year

[kamailio/kamailio] [rtpengine] Support syntax for new "sdp-attr" manipulations (Issue #3509)

by George Diamantopoulos

### Description Newer rtpengine versions support manipulating SDP "a=" lines directly. Although kamailio is quite versatile when it comes to editing SIP message body, this functionality is often rather frail, especially when forking and having to use msg_apply_changes several times. I believe it would be beneficial to be able to offload such functionality to rtpengine, especially if one wants to apply different manipulations per outgoing branch. ### Expected behavior There should be a way to issue rtpengine ng-control protocol commands compatible with the sdp-attr dictionary syntax. #### Actual observed behavior Currently sdp-attr tokens are not properly evaluated. For example, **doing**: > rtpengine_manage("ICE=remove rtcp-mux-demux trust-address replace-origin replace-session-connection replace-SDP-version direction=internal direction=external sdp-attr-audio-substitute=$avp(fmtp_line) sdp-attr-audio-substitute=fmtp:101 0-15"); _[NOTE: $avp(fmtp_line) seems to expand in empty string here, which is a config error, but it doesn't affect the syntax demonstration in this example IMO]_ **results in**: ``` { "supports": [ "load limit" ], "sdp": "...", "ICE": "remove", "sdp-attr-audio-substitute": "", "sdp-attr-audio-substitute": "fmtp:101", "direction": [ "internal", "external" ], "flags": [ "trust-address", "0-15" ], "replace": [ "origin", "session-connection", "SDP-version" ], "rtcp-mux": [ "demux" ], "call-id": "...", "received-from": [ "IP4", "..." ], "from-tag": "...", "to-tag": "...", "command": "answer" } ``` ### Possible Solutions Support the special syntax of sdp-attr as documented here: https://github.com/sipwise/rtpengine/blob/master/docs/ng_control_protocol.md Here's one way to do it (I guess). In order to get this: ``` "sdp-attr" : { "audio" : { "add" : [ "ptime:20", "sendrecv" ], "substitute": [["fmtp:101 0-15" , "fmtp:126 0-16" ]] }, "video": { "remove" : [ "rtpmap:101 telephone-event/8000" ] }, "none" : { "substitute": [[ "sendrecv" , "sendonly" ], [ "ptime:20" , "ptime:40" ]] } } ``` Use a syntax similar to the following: > rtpengine_manage("... sdp-attr-audio-add=ptime:20 sdp-attr-audio-add=sendrecv sdp-attr-audio-substitute=fmtp:101 0-15 sdp-attr-audio-substitute=fmtp:101 0-16 sdp-attr-video-remove=rtpmap:101 telephone-event/8000 sdp-attr-none-substitute=sendrecv sdp-attr-none-substitute=sendonly sdp-attr-none-substitute=ptime:20 sdp-attr-none-substitute=ptime:40 ..."); It's not very pretty, but it could work. Caveats: * How to handle whitespace (e.g. there's a space in "fmtp:101 0-15" and in "rtpmap:101 telephone-event/8000" ) * substitute commands must always be in pairs, data type is a list of lists containing exactly two items as value in "substitute" key Unfortunately my C skills are not up to this task, but if I can provide any other kind of help please let me know. Thanks! -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3509 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3509(a)github.com>

1 year

[kamailio/kamailio] core: add socket timestamp of received packets and keep track of receive delay (PR #3404)

by Nicolas C

#### 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 is a proposed evolution that adds socket timestamping of received UDP packets (using SO_TIMESTAMPNS). It computes the delay between this timestamp and the time at which the packet is read by Kamailio. This can then be accessed using pv "$TV(RD)" (RD for "receive relay"). Rationale : The Kamailio server is handling traffic that is irregular and can temporarily spike to a point where all children are still busy when new packets are incoming on the network interface. Consequently, these packets have to wait until a worker is available. The client will see a higher response time, that currently cannot be monitored by Kamailio itself. This evolution allows to make this wait time observable by Kamailio, allowing to log or write the information to CDR for example. If this is possible, I'd like to merge this feature in Kamailio. Of course, I'm ready to discuss the PR and make any necessary changes. All comments and reviews are most welcome. I've tested this locally on Linux (3.10.0-957.10.1.el7.x86_64) with the latest Kamailio master as of 2023/03/23. Thanks! You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3404 -- Commit Summary -- * core: add socket timestamp of received packets and keep track of receive delay * pv: add $TV(RD) to get the new information "receive delay" -- File Changes -- M src/core/ip_addr.h (1) M src/core/parser/msg_parser.h (1) M src/core/receive.c (8) M src/core/udp_server.c (60) M src/core/ut.h (34) M src/modules/pv/pv_time.c (15) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3404.patch https://github.com/kamailio/kamailio/pull/3404.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3404 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3404(a)github.com>

1 year

[kamailio/kamailio] Allow function set_advertised_address to receive variable as parameter (#2137)

by pwakano

1 year

[kamailio/kamailio] Memory leak in dns_cache.c / dns_cache_mk_rd_entry (Issue #3523)

by Sebastian Damm

### Description We have some Kamailio servers running as an outboundproxy. Requests go to different domains. Over the time, there is a slow but steady shared memory increase. We don't see the behavior on our Kamailio servers serving as endpoint proxies using the same code. I did a memory dump, and on two systems I inspected, I saw the same result: A really high memory usage for the `dns_cache_mk_rd_entry` function.  ### Troubleshooting #### Reproduction When we restart our Kamailio, it starts off with just a few megabytes of shared mem used. After running for a month or two, this has increased to some hundred megabytes used.  #### Debugging Data This is the output of the shm dump: ``` Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): summarizing all alloc'ed. fragments: Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 592 bytes from tm: t_reply.c: _reply_light(500) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 45 size= 43576 bytes from core: core/msg_translator.c: build_req_buf_from_sip_req(2233) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 44 size= 33232 bytes from tm: t_reply.c: relay_reply(2061) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 45 size= 376840 bytes from tm: h_table.c: build_cell(334) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 4 size= 224 bytes from pike: ip_tree.c: new_ip_node(201) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 45 size= 275304 bytes from core: core/sip_msg_clone.c: sip_msg_shm_clone(495) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 16 size= 1528 bytes from core: core/usr_avp.c: create_avp(176) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 45 size= 16728 bytes from core: core/sip_msg_clone.c: msg_lump_cloner(973) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 12 size= 488 bytes from tls: tls_ct_q.h: tls_ct_q_add(58) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 12 size= 584 bytes from tls: tls_server.c: tls_complete_init(276) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 59 size= 3776 bytes from rtpengine: ../../core/parser/../ut.h: shm_str_dup(859) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 212 size= 15720 bytes from core: core/xavp.c: xavp_new_value(116) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 59 size= 3888 bytes from rtpengine: rtpengine.c: rtpp_function_call(2775) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 29 size= 2680 bytes from core: core/dns_cache.c: dns_cache_mk_bad_entry(770) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count=856568 size= 311761008 bytes from core: core/dns_cache.c: dns_cache_mk_rd_entry(1117) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 13941 size= 2741784 bytes from htable: ht_api.c: ht_cell_new(186) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 2 size= 104 bytes from xhttp_prom: prom_metric.c: prom_metric_lvalue_create(513) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 24 size= 3752 bytes from tmx: tmx_pretran.c: tmx_check_pretran(250) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 24 size= 6776 bytes from tmx: tmx_pretran.c: tmx_check_pretran(271) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 553 size= 10177808 bytes from core: core/tcp_main.c: tcpconn_new(1175) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 53760 bytes from core: core/counters.c: counters_prefork_init(212) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 2 size= 976 bytes from tls: tls_domain.c: ksr_tls_fix_domain(1057) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8064 bytes from sl: sl_stats.c: init_sl_stats_child(125) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 512 bytes from tmx: tmx_pretran.c: tmx_init_pretran_table(90) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 10752 bytes from tm: t_stats.c: init_tm_stats_child(56) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 2016 bytes from kex: pkg_stats.c: pkg_proc_stats_init(78) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 8 size= 176 bytes from core: core/cfg/cfg_struct.c: cfg_clone_str(130) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 992 bytes from core: core/cfg/cfg_struct.c: cfg_shmize(217) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: main.c: main_loop(1334) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/pt.c: init_pt(107) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/pt.c: init_pt(106) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 6216 bytes from core: core/pt.c: init_pt(105) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from app_python3: apy_kemi.c: apy_sr_init_mod(2095) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from app_python3: apy_kemi.c: apy_sr_init_mod(2088) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from xhttp_prom: prom_metric.c: prom_metric_init(219) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 16 bytes from pike: pike.c: pike_init(127) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 1040 bytes from pike: ../../core/lock_alloc.h: lock_set_alloc(66) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 4112 bytes from pike: ip_tree.c: init_ip_tree(115) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from pike: pike.c: pike_init(109) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 4 size= 120 bytes from core: core/cfg_parser.c: cfg_parse_str(907) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 2 size= 448 bytes from tls: tls_domain.c: tls_new_domain(187) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 48 bytes from tls: tls_domain.c: tls_new_cfg(1553) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from tls: tls_ct_wrq.c: tls_ct_wq_init(49) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from tls: tls_mod.c: mod_init(373) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from tls: tls_mod.c: mod_init(357) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from siptrace: siptrace.c: mod_init(338) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 256 size= 14336 bytes from rtpengine: rtpengine_hash.c: rtpengine_hash_table_init(111) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 256 size= 2048 bytes from rtpengine: rtpengine_hash.c: rtpengine_hash_table_init(96) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 1024 bytes from rtpengine: rtpengine_hash.c: rtpengine_hash_table_init(85) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 2048 bytes from rtpengine: rtpengine_hash.c: rtpengine_hash_table_init(76) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 2048 bytes from rtpengine: rtpengine_hash.c: rtpengine_hash_table_init(67) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 32 bytes from rtpengine: rtpengine_hash.c: rtpengine_hash_table_init(58) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 24 bytes from rtpengine: rtpengine.c: add_rtpengine_socks(1021) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 64 bytes from rtpengine: rtpengine.c: add_rtpengine_socks(1002) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from rtpengine: rtpengine.c: get_rtpp_set(916) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 56 bytes from rtpengine: rtpengine.c: get_rtpp_set(907) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from rtpengine: rtpengine.c: mod_init(1683) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 24 bytes from rtpengine: rtpengine.c: mod_init(1676) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from rtpengine: rtpengine.c: mod_init(1650) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from rtpengine: rtpengine.c: mod_init(1643) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 16 bytes from rtpengine: rtpengine.c: mod_init(1629) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 5 size= 1581568 bytes from htable: ht_api.c: ht_init_tables(394) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 16 bytes from usrloc: ul_callback.c: init_ulcb_list(44) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 4 size= 288 bytes from core: core/timer.c: register_timer(995) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from sl: sl_funcs.c: sl_startup(90) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from sl: sl_stats.c: init_sl_stats(110) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 16 bytes from tm: t_hooks.c: init_tmcb_lists(71) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 16 bytes from tm: t_hooks.c: init_tmcb_lists(69) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 2097152 bytes from tm: h_table.c: init_hash_table(482) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 16 bytes from tm: rpc_uac.c: tm_rpc_response_list_init(77) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from kex: mod_stats.c: mod_stats_init_rpc(294) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 4 size= 128 bytes from core: core/cfg/cfg_ctx.c: cfg_register_ctx(47) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1089 size= 82016 bytes from tls: tls_init.c: ser_realloc(299) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8192 bytes from core: core/tcp_main.c: init_tcp(5051) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 32768 bytes from core: core/tcp_main.c: init_tcp(5046) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/tcp_main.c: init_tcp(5037) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/tcp_main.c: init_tcp(5030) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/tcp_main.c: init_tcp(5023) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/tcp_main.c: init_tcp(5017) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/tcp_main.c: init_tcp(5005) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/usr_avp.c: init_avps(90) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/usr_avp.c: init_avps(89) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 16384 bytes from core: core/dst_blocklist.c: init_dst_blocklist(437) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/dst_blocklist.c: init_dst_blocklist(430) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 2 size= 96 bytes from core: core/timer.c: timer_alloc(498) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/dns_cache.c: init_dns_cache(368) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 16384 bytes from core: core/dns_cache.c: init_dns_cache(359) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 16 bytes from core: core/dns_cache.c: init_dns_cache(351) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/dns_cache.c: init_dns_cache(343) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/timer.c: init_timer(267) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 16384 bytes from core: core/timer.c: init_timer(266) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/timer.c: init_timer(265) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/timer.c: init_timer(264) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/timer.c: init_timer(253) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/timer.c: init_timer(221) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 278544 bytes from core: core/timer.c: init_timer(210) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/timer.c: init_timer(209) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/timer.c: init_timer(197) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 64 bytes from core: core/cfg/cfg_struct.c: cfg_child_cb_new(829) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/cfg/cfg_struct.c: sr_cfg_init(361) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/cfg/cfg_struct.c: sr_cfg_init(354) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/cfg/cfg_struct.c: sr_cfg_init(347) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/cfg/cfg_struct.c: sr_cfg_init(335) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/cfg/cfg_struct.c: sr_cfg_init(323) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/sr_module.c: ksr_shutdown_phase_init(124) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 36864 bytes from core: core/kemi.c: sr_kemi_cbname_list_init(3605) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/kemi.c: sr_kemi_cbname_list_init(3596) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/kemi.c: sr_kemi_cbname_list_init(3586) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 3 size= 72 bytes from xhttp_prom: ../../core/ut.h: shm_str_dup(859) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 5 size= 96 bytes from xhttp_prom: prom_metric.c: prom_lb_node_add(813) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 5 size= 120 bytes from xhttp_prom: prom_metric.c: prom_lb_node_add(791) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 3 size= 48 bytes from xhttp_prom: prom_metric.c: prom_lb_create(873) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 3 size= 168 bytes from xhttp_prom: prom_metric.c: prom_counter_create(978) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 9 size= 128 bytes from pv: pv_shv.c: set_shvar_value(243) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 40 size= 472 bytes from pv: pv_shv.c: add_shvar(177) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 40 size= 2608 bytes from pv: pv_shv.c: add_shvar(170) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 80 bytes from pv: ../../core/lock_alloc.h: lock_set_alloc(66) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 5 size= 1600 bytes from htable: ht_api.c: ht_add_table(289) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 10464 size= 1453800 bytes from tls: tls_init.c: ser_malloc(293) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): count= 1 size= 8 bytes from core: core/mem/q_malloc.c: qm_shm_lock_init(1277) Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): ----------------------------- ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` 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 9.4.0 ``` * **DNS related kamailio.cfg Settings** ``` dns_retr_time=3 dns_retr_no=3 dns_use_search_list=no dns_try_naptr=yes use_dns_failover=yes ``` * **Operating System**:  ``` Podman container with Ubuntu Focal. ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3523 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3523(a)github.com>

1 year

[kamailio/kamailio] core: Add TCP_USER_TIMEOUT socket option on listening socket. (PR #3528)

by schoberw

Use tcp_send_timeout config option also on listening socket to timeout outbound messages sent on passive inbound connections. #### 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:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #3443 #### Description Based on the description of core parameter "tcp_send_timeout" the timeout should also work for sending on forked incoming tcp connections. But sending on a broken connection causes the kernel to use the default values of `tcp_retries1` and `tcp_retries2` , leading to try to send a SIP message for 15 minutes. This makes absolutely no sense in a real time kamailio application. Following man 7 tcp TCP_USER_TIMEOUT can be used on recent Linux kernels to utilize tcp_send_timeout: TCP_USER_TIMEOUT (since Linux 2.6.37) This option takes an unsigned int as an argument. When the value is greater than 0, it specifies the maximum amount of time in milliseconds that transmitted data may remain unacknowledged before TCP will forcibly close the corresponding connection and return ETIMEDOUT to the application. If the option value is specified as 0, TCP will use the system default. Increasing user timeouts allows a TCP connection to survive extended periods without end-to-end connectivity. De‐ creasing user timeouts allows applications to "fail fast", if so desired. Otherwise, failure may take up to 20 minutes with the current system defaults in a normal WAN environment. This option can be set during any state of a TCP connection, but is effective only during the synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, and LAST-ACK). Moreover, when used with the TCP keepalive (SO_KEEPALIVE) option, TCP_USER_TIMEOUT will override keepalive to determine when to close a connection due to keepalive failure. The option has no effect on when TCP retransmits a packet, nor when a keepalive probe is sent. This option, like many others, will be inherited by the socket returned by accept(2), if it was set on the listen‐ ing socket. Further details on the user timeout feature can be found in RFC 793 and RFC 5482 ("TCP User Timeout Option"). Having a tcp connection break by firewall or network breakdown the retransmits to this destination are now aborted after `tcp_send_timeout` seconds with a NOTICE: <core> [core/tcp_read.c:267]: tcp_read_data(): error reading: Connection timed out (110) ([1.2.3.4]:51151 -> You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3528 -- Commit Summary -- * core: Add TCP_USER_TIMEOUT socket option on listening socket. -- File Changes -- M src/core/tcp_main.c (13) M src/core/tcp_options.h (7) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3528.patch https://github.com/kamailio/kamailio/pull/3528.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3528 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3528(a)github.com>

1 year

← Newer
1
...
8
9
10
11
12
13
14
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev August 2023